On Monday, June 3, 2019 3:30:08 PM CDT Robbie Harwood wrote:
> Simo Sorce <simo(a)redhat.com> writes:
> > On Sun, 2019-06-02 at 18:00 -0500, Anthony Joseph Messina wrote:
> >> I'm using Apache with GSS-Proxy and the following systemd
> >> httpd.service.d/
> >> httpd-gssproxy.conf drop-in, enabling transfer of the HTTP service
> >> principal without Apache having direct access to the HTTP service
> >> keytab:
> >>
> >> [Service]
> >> Environment=KRB5CCNAME=/run/httpd/clientcaches/krb5cc-httpd
> >> Environment=GSS_USE_PROXY=yes
> >>
> >> I also have a number Apache Location directives as follows:
> >>
> >> <Location>
> >>
> >> ...
> >> GssapiDelegCcacheDir /run/httpd/clientcaches
> >> GssapiDelegCcacheUnique On
> >> ...
> >>
> >> </Location>
> >>
> >> This is all working wonderfully and credentials are set as
> >> /run/httpd/clientcaches/user(a)EXAMPLE.COM-Q1pBaI
> >>
> >> Reviewing the documentation I know I'll need to cleanup these unique
> >> ccaches, however all the unique ccaches are encrypted like the following
> >>
> >> # klist -c user(a)EXAMPLE.COM-Q1pBaI
> >> Ticket cache: FILE:user@EXAMPLE.COM-Q1pBaI
> >> Default principal: user(a)EXAMPLE.COM
> >>
> >> Valid starting Expires Service principal
> >> 12/31/1969 18:00:00 12/31/1969 18:00:00
> >> Encrypted/Credentials/v1@X-GSSPROXY:
> >>
> >> The sweeper.py in the mod_auth_gssapi source doesn't seem to be able to
> >> handle this, thinking that each ccache is already expired.
> >>
> >> Can you offer other suggestions for cleaning these out based on their
> >> actual expiry? Thank you. -A
> >
> > Uhm you make a good point that there isn't a simple way to figure out
> > what the actual expiration time within the encrypted cache is.
> >
> > I can only offer a hack where you try to use this credential, through
> > gss-proxy to try to connect to a select host you know exist, and see
> > if the GSSAPI conversation succeeds or fails with an error about
> > credentials being invalid/expired. On failure you would remove the
> > ccache.
> >
> > It's the best I can offer right now.
> > And I know it is not great as this means network traffic.
> >
> > ... and now I am thinking we have another way.
> >
> > It is probably sufficient to use gss_acuire_cred_from() and specify
> > the ccache you want to check, then run gss_inquire_cred(). Check the
> > lifetime is greater than 300s (5 min clock skew), or whatever minimum
> > time you think makes sense. (if you had 1s left it wouldn't be a
> > useful cred anyway). You can also only check for lifetime > 0. Again
> > if you get an error thatthe credential is not valid you can also just
> > delete it. This should work w/o network connections.
> >
> > You can also set the GSS Proxy behavior for this tool to REMOTE_ONLY so
> > you avoid the chance the mechglue will try to obtain local creds.
> >
> > If you use python-gssapi you can easily test out the commands with the
> > shell and then implement a python script.
>
> This is basically what the sweeper does already: it uses python-gssapi,
> calls acquire_cred_from, and checks lifetime (results in an inquire_cred
> call).
>
https://github.com/modauthgssapi/mod_auth_gssapi/blob/master/contrib/sweeper
> .py#L47
>
> Thanks,
> --Robbie
If it's of any use in the interim, these are my results using the current sweeper.py
in git master:
-rw-------. 1 apache apache 2636 Jun 3 17:04 user(a)EXAMPLE.COM-BlfcSj
-rw-------. 1 apache apache 2636 Jun 3 16:39 user(a)EXAMPLE.COM-hekRb5
-rw-------. 1 apache apache 3844 Jun 2 12:36 user(a)EXAMPLE.COM-IVoIf0
-rw-------. 1 apache apache 3844 Jun 2 12:48 user(a)EXAMPLE.COM-MvWD3h
-rw-------. 1 apache apache 3844 Jun 3 16:38 user(a)EXAMPLE.COM-O1VzDi
-rw-------. 1 apache apache 3844 Jun 2 10:16 user(a)EXAMPLE.COM-oi4Os0
-rw-------. 1 apache apache 3844 Jun 2 18:05 user(a)EXAMPLE.COM-PbGuFZ
-rw-------. 1 apache apache 3844 Jun 2 16:01 user(a)EXAMPLE.COM-Q1pBaI
-rw-------. 1 apache apache 3844 Jun 3 05:51 user(a)EXAMPLE.COM-Qp2fLX
-rw-------. 1 apache apache 3844 Jun 3 07:21 user(a)EXAMPLE.COM-RMfcxJ
-rw-------. 1 apache apache 3844 Jun 3 17:03 user(a)EXAMPLE.COM-Y6LNiA
-rw-------. 1 apache apache 3844 Jun 3 11:39 user(a)EXAMPLE.COM-z5F1ci
Not deleting user(a)EXAMPLE.COM-hekRb5 due to error Major (851968): Unspecified GSS
failure. Minor code may provide more information, Minor (39756044): Credential cache is
empty
Not deleting user(a)EXAMPLE.COM-O1VzDi due to error Major (851968): Unspecified GSS
failure. Minor code may provide more information, Minor (39756044): Credential cache is
empty
Not deleting user(a)EXAMPLE.COM-z5F1ci due to error Major (851968): Unspecified GSS
failure. Minor code may provide more information, Minor (39756044): Credential cache is
empty
Not deleting user(a)EXAMPLE.COM-RMfcxJ due to error Major (851968): Unspecified GSS
failure. Minor code may provide more information, Minor (39756044): Credential cache is
empty
Not deleting user(a)EXAMPLE.COM-Qp2fLX due to error Major (851968): Unspecified GSS
failure. Minor code may provide more information, Minor (39756044): Credential cache is
empty
Not deleting user(a)EXAMPLE.COM-PbGuFZ due to error Major (851968): Unspecified GSS
failure. Minor code may provide more information, Minor (39756044): Credential cache is
empty
Not deleting user(a)EXAMPLE.COM-Q1pBaI due to error Major (851968): Unspecified GSS
failure. Minor code may provide more information, Minor (39756044): Credential cache is
empty
Not deleting user(a)EXAMPLE.COM-MvWD3h due to error Major (851968): Unspecified GSS
failure. Minor code may provide more information, Minor (39756044): Credential cache is
empty
Not deleting user(a)EXAMPLE.COM-IVoIf0 due to error Major (851968): Unspecified GSS
failure. Minor code may provide more information, Minor (39756044): Credential cache is
empty
Not deleting user(a)EXAMPLE.COM-oi4Os0 due to error Major (851968): Unspecified GSS
failure. Minor code may provide more information, Minor (39756044): Credential cache is
empty