Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Feedback-ID: iffc1478b:Fastmail
Date:   Mon, 24 Apr 2023 14:28:17 -0400
From:   Ben Boeckel <me@benboeckel.net>
To:     Scott Mayhew <smayhew@redhat.com>
Cc:     linux-nfs@vger.kernel.org, keyrings@vger.kernel.org
Subject: Re: [RFC PATCH 5/5] SUNRPC: store GSS creds in keyrings
Message-ID: <20230424182817.GA1118847@farprobe>
References: <20230420202004.239116-1-smayhew@redhat.com>
 <20230420202004.239116-6-smayhew@redhat.com>
 <20230422212710.GA813856@farprobe>
 <ZEaL8Wueo5/vOGTg@aion.usersys.redhat.com>
 <20230424142309.GB1072182@farprobe>
 <ZEaZ5sLo2nBXUjl/@aion.usersys.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <ZEaZ5sLo2nBXUjl/@aion.usersys.redhat.com>
User-Agent: Mutt/2.2.9 (2022-11-12)
Precedence: bulk

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