[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-keyrings
Subject:    Re: [RFC PATCH 5/5] SUNRPC: store GSS creds in keyrings
From:       Ben Boeckel <me () benboeckel ! net>
Date:       2023-04-24 18:28:17
Message-ID: 20230424182817.GA1118847 () farprobe
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]