Linux NFS development
 help / color / mirror / Atom feed
From: Scott Mayhew <smayhew@redhat.com>
To: Ben Boeckel <me@benboeckel.net>
Cc: linux-nfs@vger.kernel.org, keyrings@vger.kernel.org
Subject: Re: [RFC PATCH 5/5] SUNRPC: store GSS creds in keyrings
Date: Mon, 24 Apr 2023 10:02:25 -0400	[thread overview]
Message-ID: <ZEaL8Wueo5/vOGTg@aion.usersys.redhat.com> (raw)
In-Reply-To: <20230422212710.GA813856@farprobe>

On Sat, 22 Apr 2023, Ben Boeckel wrote:

> On Thu, Apr 20, 2023 at 16:20:04 -0400, Scott Mayhew wrote:
> > This patch adds the option to store GSS credentials in keyrings as an
> > alternative to the RPC credential cache, to give users the ability to
> > destroy their GSS credentials on demand via 'keyctl unlink'.
> 
> Can documentation please be added to `Documentation/security/keys` about
> this key type?

I'll work on that.

> 
> > Summary of the changes:
> > 
> > - Added key_type key_type_gss_cred and associated functions.  The
> >   request_key function makes use of the existing upcall mechanism to
> >   gssd.
> > 
> > - Added a keyring to the gss_auth struct to allow all of the assocated
> >   GSS credentials to be destroyed on RPC client shutdown (when the
> >   filesystem is unmounted).
> > 
> > - The key description contains the RPC client id, the user id, and the
> >   principal (for machine creds).
> 
> What is the format of this within the bytes?

The format is "clid: <client-id> id: <fsuid> princ:<princ>", where
client-id and fsuid are unsigned ints and princ is either "(none)" or
"*" if it's a machine cred:

crash> p ((struct key *) 0xffff8b4410197900)->description
$1 = 0xffff8b4446cbd740 "clid:1 id:1000 princ:(none)"

> 
> > - The key payload contains the address of the gss_cred.
> 
> What is the format of this within the bytes?

The payload is just a pointer:

crash> p ((struct key *) 0xffff8b4410197900)->payload.data[0]
$2 = (void *) 0xffff8b44381cd480

> 
> > - The key is linked to the user's user keyring (KEY_SPEC_USER_KEYRING)
> >   as well as to the keyring on the gss_auth struct.
> 
> Where is this documented? Can the key be moved later?

It's not - I can add that to the documentation for the new key type.
The key should not be moved.  I haven't tested if it's possible to move
it, but it's something that we'd want to disallow.

-Scott
> 
> > - gss_cred_init() now takes an optional pointer to an authkey, which is
> >   passed down to gss_create_upcall() and gss_setup_upcall(), where it is
> >   added to the gss_msg.  This is used for complete_request_key() after
> >   the upcall is done.
> > 
> > - put_rpccred() now returns a bool to indicate whether it called
> >   crdestroy(), and is used by gss_key_revoke() and gss_key_destroy() to
> >   determine whether to clear the key payload.
> > 
> > - gss_fill_context() now returns the GSS context's timeout via the tout
> >   parameter, which is used to set the timeout of the key.
> > 
> > - Added the module parameter 'use_keyring'.  When set to true, the GSS
> >   credentials are stored in the keyrings.  When false, the GSS
> >   credentials are stored in the RPC credential caches.
> > 
> > - Added a tracepoint to log the result of the key request, which prints
> >   either the key serial or an error return value.
> > 
> > Signed-off-by: Scott Mayhew <smayhew@redhat.com>
> > ---
> >  include/linux/sunrpc/auth.h    |   4 +-
> >  include/trace/events/rpcgss.h  |  46 ++++-
> >  net/sunrpc/auth.c              |   9 +-
> >  net/sunrpc/auth_gss/auth_gss.c | 338 +++++++++++++++++++++++++++++++--
> >  4 files changed, 376 insertions(+), 21 deletions(-)
> 
> Thanks,
> 
> --Ben
> 


  reply	other threads:[~2023-04-24 14:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-20 20:19 [RFC PATCH 0/5] SUNRPC: Add option to store GSS credentials in Scott Mayhew
2023-04-20 20:20 ` [RFC PATCH 1/5] keys: export keyring_ptr_to_key() Scott Mayhew
2023-04-20 20:20 ` [RFC PATCH 2/5] keys: add keyring_gc_custom() Scott Mayhew
2023-04-20 20:20 ` [RFC PATCH 3/5] keys: add dest_keyring parameter to request_key_with_auxdata() Scott Mayhew
2023-04-20 20:20 ` [RFC PATCH 4/5] keys: add the ability to search user keyrings in search_cred_keyrings_rcu() Scott Mayhew
2023-04-20 20:20 ` [RFC PATCH 5/5] SUNRPC: store GSS creds in keyrings Scott Mayhew
2023-04-22 21:27   ` Ben Boeckel
2023-04-24 14:02     ` Scott Mayhew [this message]
2023-04-24 14:23       ` Ben Boeckel
2023-04-24 15:01         ` Scott Mayhew
2023-04-24 18:28           ` Ben Boeckel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZEaL8Wueo5/vOGTg@aion.usersys.redhat.com \
    --to=smayhew@redhat.com \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=me@benboeckel.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox