[RFC PATCH 0/5] SUNRPC: Add option to store GSS credentials in

[Scott Mayhew <smayhew@redhat.com>]

These patches are a work in progress.  They add the option to store GSS
credentials in user keyrings as an alternative to the credential cache
hashtables that are currently used.  The goal is to give users the
ability to destroy their credentials on-demand.

There have been other attempts to give users the ability to destroy
their GSS credentials in the past, for example:

https://lore.kernel.org/all/1354560315-2393-2-git-send-email-andros@netapp.com/T/
and
https://lore.kernel.org/linux-nfs/20170807212355.29127-1-kolga@netapp.com/

But those attempts were not accepted, so I wanted to get some feedback
on what I currently have before trying to tackle some of the more thorny
issues, such as what to do when a user has files open for write,
potentially with dirty data to be written out.

These patches are also available at:
https://github.com/scottmayhew/linux/tree/gss-cred-keyring

Here's a quick demo:

[smayhew@centos9 ~]$ sudo mount nfs:/export /mnt/t
[smayhew@centos9 ~]$ ls -l /mnt/t/test[12]
-rw-r--r--. 1 testuser1 testuser1 32 Apr 20 15:34 /mnt/t/test1
-rw-r--r--. 1 testuser2 testuser2 32 Apr 20 15:33 /mnt/t/test2

[smayhew@centos9 ~]$ kinit testuser1
Password for testuser1@SMAYHEW2.TEST: 

[smayhew@centos9 ~]$ date >/mnt/t/test1

[smayhew@centos9 ~]$ keyctl show
Session Keyring
 400651412 --alswrv   1000  1000  keyring: _ses
 376802674 --alswrv   1000 65534   \_ keyring: _uid.1000
 297894262 --als--v   1000  1000       \_ gss_cred: clid:1 id:1000 princ:(none)

[smayhew@centos9 ~]$ date >/mnt/t/test2
-bash: /mnt/t/test2: Permission denied

[smayhew@centos9 ~]$ kinit testuser2
Password for testuser2@SMAYHEW2.TEST: 

[smayhew@centos9 ~]$ keyctl unlink 297894262
1 links removed

Note: At this point the old gss_cred hasn't actually been destroyed,
because the key that is referencing it is also linked to a special
keyring hanging off the gss_auth structure.  When the user creates a new
gss_cred and the key referencing the new gss_cred is linked to the
gss_auth keyring, that causes the old gss_cred to be destroyed and a 
RPCSEC_GSS_DESTROY is sent to the server.  If the user were to unlink
their gss_cred key and do nothing else, then the cred would be destroyed
when the gss_auth is destroyed (i.e. on umount).

[smayhew@centos9 ~]$ keyctl show
Session Keyring
 400651412 --alswrv   1000  1000  keyring: _ses
 376802674 --alswrv   1000 65534   \_ keyring: _uid.1000

[smayhew@centos9 ~]$ date >/mnt/t/test2

[smayhew@centos9 ~]$ keyctl show
Session Keyring
 400651412 --alswrv   1000  1000  keyring: _ses
 376802674 --alswrv   1000 65534   \_ keyring: _uid.1000
  83204766 --als--v   1000  1000       \_ gss_cred: clid:1 id:1000 princ:(none)

[smayhew@centos9 ~]$ date >/mnt/t/test1
-bash: /mnt/t/test1: Permission denied

-Scott

Scott Mayhew (5):
  keys: export keyring_ptr_to_key()
  keys: add keyring_gc_custom()
  keys: add dest_keyring parameter to request_key_with_auxdata()
  keys: add the ability to search user keyrings in
    search_cred_keyrings_rcu()
  SUNRPC: store GSS creds in keyrings

 fs/nfs/nfs4idmap.c             |   2 +-
 include/linux/key.h            |   9 +-
 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 +++++++++++++++++++++++++++++++--
 security/keys/internal.h       |   1 +
 security/keys/keyring.c        |  16 +-
 security/keys/process_keys.c   |  78 ++++++--
 security/keys/request_key.c    |   5 +-
 10 files changed, 470 insertions(+), 38 deletions(-)

-- 
2.39.2