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@xxxxxxxxxx/T/ and https://lore.kernel.org/linux-nfs/20170807212355.29127-1-kolga@xxxxxxxxxx/ 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@xxxxxxxxxxxxx: [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@xxxxxxxxxxxxx: [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
