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
Thank you. I'll check into this further. From my quick testing,t eh
sweeper.py seemed to indicate that they were all expired. Let me see if I can
do more this weekend on this. I appreciate you both pointing me in the right
direction. -A
--
Anthony -
https://messinet.com
F9B6 560E 68EA 037D 8C3D D1C9 FF31 3BDB D9D8 99B6