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.
HTH,
Simo.
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
_______________________________________________
gss-proxy mailing list -- gss-proxy(a)lists.fedorahosted.org
To unsubscribe send an email to gss-proxy-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/gss-proxy@lists.fedorahosted...
--
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc