On Mon, Apr 24, 2023 at 11:01:58 -0400, Scott Mayhew wrote:
> Just to be clear, this isn't meant to be written or read by userspace.
> The user isn't explicitly requesting the creation of a key with the
> gss_cred key type. It happens automatically when they access an NFS
> filesystem mounted with "sec=krb5{,i,p}", using the existing upcall
> mechanism to rpc.gssd. The only difference is that instead of sticking
> the resulting gss_cred in the rpc_auth.au_credcache hash table, we're
> now creating a key with the address of the gss_cred and storing it in
> keyrings.
Ah, ok. I'm mostly interested in the userspace side as the author of
https://github.com/mathstuf/rust-keyutils which I try to keep some safe
wrappers around various keytypes.
> We definitely allow unlinking - that's sort of the whole point because
> it allows users to establish a new GSS credential (most likely with a
> different initiator principal that the old one).
>
> It doesn't really make sense for the key to be on any other keyring besides
> the user keyring. If it were on the session keyring, and if you were
> logged into multiple sessions, then those sessions would be constantly
> whacking each others GSS creds and they be constantly
> creating/destroying new GSS creds with the NFS server.
>
> Having them on the session keyring also presents another problem because
> the NFS client caches NFSv4 open owners, which take a reference on a
> struct cred. When you log out, pam_keyinit revokes the session keying.
> If you log back in and try to resume NFS access (generating a new key),
> the current request key code will find the cred with the revoked session
> keyring, and it will try to link the new key to that revoked session
> keyring, which will then fail with -EKEYREVOKED. That's the reason
> for patches 3/5 and 4/5, to allow request_key_with_auxdata() to link the
> key directly to the user keyring.
Ok. These lifetime things definitely deserve docs.
Thanks,
--Ben
