* [PATCH 0/1] RFC: enable the use of the KEYRING credential cache
@ 2012-12-03 18:45 andros
2012-12-03 18:45 ` [PATCH 1/1] SUNRPC: new keyring key_type for gss context destruction at kdestroy andros
0 siblings, 1 reply; 7+ messages in thread
From: andros @ 2012-12-03 18:45 UTC (permalink / raw)
To: trond.myklebust; +Cc: linux-nfs, Andy Adamson
From: Andy Adamson <andros@netapp.com>
This is a request for comments patch set. It is the nfs-utils portion of a solution for synchronizing the Kerberos credential and gss_context credential destruction.
The keyring is used as it provides a known place for the Kerberos credentials used by NFS, and built-in kernel callbacks that can be used for kerberos credential and gss context synchronization.
The design is for the auth_rpcgss module to register a new key type, the "gss-ctx" key, whose methods can be used for some gss context managment. This key is added to the kerberos keyring and contains any information needed for Kerberos based gss context managememnt.
Currently, the uid is stored in the gss-ctx key and the destroy method is implemented to destroy all Kerberos gss_contexts for the uid.
This design requires new nfslogin/nfslogout programs to be used. The nfslogin and logout programs do two tasks.
1) enforce the keyring nameing convention required for GSSD to use keyrings.
2) create/destroy/update the gss-ctx key used to synhronize the gss context withthe kerberos credential cache.
There are three pieces to this design: GSSD patches, new (yet to be officially written) nfslogin/nfslogout, and KERNEL pactches.
------------------------
GSSD code:
There are two pieces:
1) Enabling GSSD to use the Kerberos KEYRING credential cache - the two patches
2) New nfslogin and nfslogout programs to be used for kerberos NFS mounts.
This code enables GSSD to use the Kerberos 5 supported KEYRING credential cache.
GSSD: Add keyring ccache for machine credential
GSSD: gssd_setup_krb5_user_keyring_ccache
Motivation:
In order for GSSD to use the Krb5 KEYRING credential type, a naming convention
is required. Use the same credential cache naming convention as used for the
FILE or MEMORY credential cache names, without a path name component:
KEYRING:krb5cc_<UID>
------------------------
NEW EXECUTABLES:
Proposed new executable: nfslogin:
This program will kinit -c KEYRING:krb5cc_<UID>, enforcing the keyring naming
convetion required by GSSD, and then create a gss-ctx key which holds the UID
as a payload, and is placed in the krb5cc_<UID> keyring.
What I do for testing is what nfslogin will do:
# kinit -c KEYRING:krb5cc_<UID>
# nfs-add-key UID krb5cc_<UID>
For destruction, I run:
# kdestroy -c KEYRING:krb5cc_<UID>
The kdestroy removes the krb5cc_<UID> keyring which causes the gss-ctx key to bedestroyed, and the destroy method removes the UID's kerberos gss contexts.
Here is the nfs-add-key userlevel code that creates the gss-ctx key:
#include <sys/types.h>
#include <keyutils.h>
#include <stdio.h>
#include <errno.h>
main (int ac, char **av)
{
char *keyring_name;
int uid;
key_serial_t key_serial, ring_serial;
if (ac != 3) {
fprintf(stderr, "Usage: %s <uid> <keyring file name>\n",
av[0]);
return;
}
uid = atoi(av[1]);
keyring_name = av[2];
fprintf(stderr, "uid: [%d], keyring:[%s]\n", uid, keyring_name);
ring_serial = request_key("keyring", keyring_name ,NULL,
KEY_SPEC_SESSION_KEYRING);
if (ring_serial < 0) {
perror("request_key failed\n");
return;
}
key_serial = add_key("gss-ctx","_nfs_gss_", &uid, sizeof(int),
ring_serial);
if (key_serial < 0) {
perror("add_key failed\n");
return;
}
}
Proposed new executable: nfslogout:
This program will call kdestroy -c KEYRING:krb5cc_<UID>, enforcing the naming
convetion required by GSSD. Destroying the krb5cc_<UID> keyring calls the
destroy callback on the gss-ctx key, which in turn uses the UID to search all
rpc_clnt gss_auth Kerberos mechanism credential caches and marks all found
gss credentials as not uptodate. This results in immediate revocation of
NFS access for the UID.
------------------------
KERNEL code:
The kernel portion of this request for comments, patch:
"SUNRPC: new keyring key_type for gss context destruction at kdestroy"
does the following:
- registers a new key_type "gss-ctx" used by nfslogin/nfslogout. nfslogin stores the uid in the key.
- the gss-ctx destroy method uses the stored uid to search all gss_auth kerberos rpc client credential caches for the uid's gss contexts and marks them as not up to date.
-----------------------
TESTING
Here is the rpc.gssd -K -f -vvv output for mount:
[root@fedora-64-2 andros]# mount -o minorversion=1,sec=krb5 vs1-d2.androsad.fake:/nfs4krb5 /mnt
Note GSSD creates and finds the KEYRING machine credential cache:
handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clntb)
handle_gssd_upcall: 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2 '
handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clntb)
process_krb5_upcall: service is '<null>'
Full hostname for 'vs1-d2.androsad.fake' is 'vs1-d2.androsad.fake'
Full hostname for 'fedora-64-2.androsad.fake' is 'fedora-64-2.androsad.fake'
No key table entry found for FEDORA-64-2.ANDROSAD.FAKE$@ANDROSAD.FAKE while getting keytab entry for 'FEDORA-64-2.ANDROSAD.FAKE$@ANDROSAD.FAKE'
No key table entry found for root/fedora-64-2.androsad.fake@ANDROSAD.FAKE while getting keytab entry for 'root/fedora-64-2.androsad.fake@ANDROSAD.FAKE'
Success getting keytab entry for 'nfs/fedora-64-2.androsad.fake@ANDROSAD.FAKE'
INFO: Credentials in CC 'KEYRING:krb5ccmachine_ANDROSAD.FAKE' are good until 1354298952
INFO: Credentials in CC 'KEYRING:krb5ccmachine_ANDROSAD.FAKE' are good until 1354298952
using KEYRING:krb5ccmachine_ANDROSAD.FAKE as credentials cache for machine creds
using environment variable to select krb5 ccache KEYRING:krb5ccmachine_ANDROSAD.FAKE
creating context using fsuid 0 (save_uid 0)
creating tcp client for server vs1-d2.androsad.fake
DEBUG: port already set to 2049
creating context with server nfs@vs1-d2.androsad.fake
DEBUG: serialize_krb5_ctx: lucid version!
prepare_krb5_rfc1964_buffer: serializing keys with enctype 4 and length 8
doing downcall lifetime_rec 1791
Closing 'gssd' pipe for /var/lib/nfs/rpc_pipefs/nfs/clnta
destroying client /var/lib/nfs/rpc_pipefs/nfs/clnta
Closing 'gssd' pipe for /var/lib/nfs/rpc_pipefs/nfs/clnt9
destroying client /var/lib/nfs/rpc_pipefs/nfs/clnt9
Here is the uid 0 keyring display from /proc
root@fedora-64-2 andros]# cat /proc/keys
05df6597 I--Q--- 1 7m 3f010000 0 0 id_legacy uid:root@androsad.fake: 2
06acf7c5 I--Q--- 1 7m 3f010000 0 0 id_legacy gid:root@androsad.fake: 2
085fd14d I--Q--- 2 perm 1f3f0000 0 65534 keyring _uid.0: empty
127383c6 I--Q--- 1 9m 3f010000 0 0 id_legacy uid:nfs@androsad.fake: 3
25fa46e8 I--Q--- 1 7m 3f010000 0 0 id_legacy gid:daemon@androsad.fake: 2
27de7437 I--Q--- 1 9m 3f010000 0 0 id_legacy gid:unixgroup@androsad.fake: 3
2ebec4f3 I------ 1 perm 1f030000 0 0 keyring .dns_resolver: empty
2fd3ad40 I--Q--- 1 perm 1f3f0000 1000 65534 keyring _uid.1000: empty
322e313d I------ 1 perm 1f030000 0 0 keyring .id_resolver: 12/12
344c5dd9 I--Q--- 101 perm 1f3f0000 1000 1000 keyring _ses: 1/4
3a28e301 I--Q--- 1 9m 3f010000 0 0 id_legacy uid:andros@androsad.fake: 5
3a761f99 I--Q--- 1 perm 1f3f0000 0 65534 keyring _uid_ses.0: 1/4
[root@fedora-64-2 andros]#
Here I run "nfslogin", a kinit then nfs-add-key:
andros@fedora-64-2 ~]$ kinit -c KEYRING:/krb5cc_1000
Password for andros@ANDROSAD.FAKE:
[andros@fedora-64-2 ~]$ cat /proc/keys
05c7977b I--Q--- 1 perm 3b3f0000 1000 1000 user __krb5_princ__: 35
08a57967 I--Q--- 1 perm 3b3f0000 1000 1000 keyring krb5cc_1000: empty
11909595 I--Q--- 1 perm 3b3f0000 1000 1000 user krbtgt/ANDROSAD.FAKE@ANDROSAD.FAKE: 465
2fd3ad40 I--Q--- 1 perm 1f3f0000 1000 65534 keyring _uid.1000: empty
344c5dd9 I--Q--- 101 perm 1f3f0000 1000 1000 keyring _ses: 3/4
3e12b317 I--Q--- 1 perm 3b3f0000 1000 1000 keyring /krb5cc_1000: 2/4
[andros@fedora-64-2 ~]$ /usr/local/src/nfs-keyring/nfs-add-key 1000 krb5cc_1000
uid: [1000], keyring:[krb5cc_1000]
[andros@fedora-64-2 ~]$ cat /proc/keys
05c7977b I--Q--- 1 perm 3b3f0000 1000 1000 user __krb5_princ__: 35
08a57967 I--Q--- 1 perm 3b3f0000 1000 1000 keyring krb5cc_1000: 1/4
11909595 I--Q--- 1 perm 3b3f0000 1000 1000 user krbtgt/ANDROSAD.FAKE@ANDROSAD.FAKE: 465
2fd3ad40 I--Q--- 1 perm 1f3f0000 1000 65534 keyring _uid.1000: empty
3281f83c I--Q--- 1 perm 3b3b0000 1000 1000 gss-ctx _nfs_gss_: 4
344c5dd9 I--Q--- 101 perm 1f3f0000 1000 1000 keyring _ses: 3/4
3e12b317 I--Q--- 1 perm 3b3f0000 1000 1000 keyring /krb5cc_1000: 2/4
Here I ls the mount point:
[andros@fedora-64-2 ~]$ ls /mnt
8.c dir2 fialplease.txt new.txt test
9.c expired4.txt fial.txt ooops.c thisisbad
andros fake.txt heh.c real yech.txt
dir fial1.txt isittrue.txt really
[andros@fedora-64-2 ~]$ cat /proc/keys
0009a221 I--Q--- 1 perm 3b3f0000 0 0 user __krb5_princ__: 61
0421323a I--Q--- 1 perm 3b3f0000 1000 1000 user __krb5_princ__: 35
0a941505 I--Q--- 1 perm 3b3f0000 0 0 user krbtgt/ANDROSAD.FAKE@ANDROSAD.FAKE: 516
0f570859 I--Q--- 1 perm 3b3f0000 1000 1000 user krbtgt/ANDROSAD.FAKE@ANDROSAD.FAKE: 465
1f7e3860 I--Q--- 1 perm 3b3b0000 1000 1000 gss-ctx _nfs_gss_: 4
30f2d34e I--Q--- 1 perm 3b3f0000 1000 0 user nfs/vs1-d2.androsad.fake@ANDROSAD.FAKE: 426
3474b7a1 I--Q--- 1 perm 3b3f0000 1000 1000 keyring krb5cc_1000: 4/4
383d58cd I--Q--- 1 perm 3b3f0000 0 0 keyring krb5ccmachine_ANDROSAD.FAKE: 3/4
3a17c360 I--Q--- 101 perm 1f3f0000 1000 1000 keyring _ses: 3/4
3f8e77d2 I--Q--- 1 perm 3b3f0000 0 0 user nfs/vs1-d2.androsad.fake@ANDROSAD.FAKE: 476
3fa78549 I--Q--- 1 perm 1f3f0000 1000 65534 keyring _uid.1000: empty
Here I kdestroy which also destroys the gss_context thus the immediate return of permission denied when trying to access the mount point:
Note that the keys are all gone including the gss-ctx key.
[andros@fedora-64-2 ~]$ kdestroy -c KEYRING:krb5cc_1000
[andros@fedora-64-2 ~]$ ls /mnt
ls: cannot access /mnt: Permission denied
[andros@fedora-64-2 ~]$ cat /proc/keys
0009a221 I--Q--- 1 perm 3b3f0000 0 0 user __krb5_princ__: 61
05a48686 I--Q--- 1 perm 3b3f0000 0 0 keyring krb5cc_1000: empty
0a941505 I--Q--- 1 perm 3b3f0000 0 0 user krbtgt/ANDROSAD.FAKE@ANDROSAD.FAKE: 516
383d58cd I--Q--- 1 perm 3b3f0000 0 0 keyring krb5ccmachine_ANDROSAD.FAKE: 3/4
3a17c360 I--Q--- 101 perm 1f3f0000 1000 1000 keyring _ses: 3/4
3f8e77d2 I--Q--- 1 perm 3b3f0000 0 0 user nfs/vs1-d2.androsad.fake@ANDROSAD.FAKE: 476
3fa78549 I--Q--- 1 perm 1f3f0000 1000 65534 keyring _uid.1000: empty
[andros@fedora-64-2 ~]$ kk
Andy Adamson (1):
SUNRPC: new keyring key_type for gss context destruction at kdestroy
net/sunrpc/auth_gss/auth_gss.c | 85 ++++++++++++++++++++++++++++++++++++++++
1 files changed, 85 insertions(+), 0 deletions(-)
--
1.7.7.6
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH 1/1] SUNRPC: new keyring key_type for gss context destruction at kdestroy
2012-12-03 18:45 [PATCH 0/1] RFC: enable the use of the KEYRING credential cache andros
@ 2012-12-03 18:45 ` andros
2012-12-03 21:06 ` Myklebust, Trond
0 siblings, 1 reply; 7+ messages in thread
From: andros @ 2012-12-03 18:45 UTC (permalink / raw)
To: trond.myklebust; +Cc: linux-nfs, Andy Adamson
From: Andy Adamson <andros@netapp.com>
This code works in conjunction with nfslogin and nfslogout programs
which enforce the use of the keyring Kerberos credential cache of the
form KEYRING:krb5cc_<UID> and adds a gss-ctx key to the krb5cc_<UID> keyring.
When kdestroy is called on the keyring context the .destroy function of the
new key is called which marks all gss_context's associated with the UID as
out of date.
Signed-off-by: Andy Adamson <andros@netapp.com>
---
net/sunrpc/auth_gss/auth_gss.c | 85 ++++++++++++++++++++++++++++++++++++++++
1 files changed, 85 insertions(+), 0 deletions(-)
diff --git a/net/sunrpc/auth_gss/auth_gss.c b/net/sunrpc/auth_gss/auth_gss.c
index 082e579..2d8fbf1 100644
--- a/net/sunrpc/auth_gss/auth_gss.c
+++ b/net/sunrpc/auth_gss/auth_gss.c
@@ -51,6 +51,12 @@
#include <linux/sunrpc/rpc_pipe_fs.h>
#include <linux/sunrpc/gss_api.h>
#include <asm/uaccess.h>
+#include <linux/key.h>
+#include <linux/keyctl.h>
+#include <linux/key-type.h>
+#include <keys/user-type.h>
+
+#include "../netns.h"
static const struct rpc_authops authgss_ops;
@@ -95,6 +101,83 @@ static void gss_free_ctx(struct gss_cl_ctx *);
static const struct rpc_pipe_ops gss_upcall_ops_v0;
static const struct rpc_pipe_ops gss_upcall_ops_v1;
+/*
+ * Search all rpc_clnt auth's and invalidate any RPC_AUT_GSS Kerberos
+ * gss contexts belonging to uid. Triggered by kdestroy of keyring
+ * kerberos credentials.
+ */
+static void
+gss_kdestroy_cred(uid_t uid)
+{
+ struct net *net = current->nsproxy->net_ns;
+ struct sunrpc_net *sn = net_generic(net, sunrpc_net_id);
+ struct rpc_clnt *clnt;
+ struct rpc_cred *cr;
+ struct auth_cred ac = {
+ .uid = uid,
+ };
+
+ dprintk("--> %s uid %d\n", __func__, uid);
+ spin_lock(&sn->rpc_client_lock);
+ list_for_each_entry(clnt, &sn->all_clients, cl_clients) {
+ if ((clnt->cl_auth->au_flavor == RPC_AUTH_GSS_KRB5) ||
+ (clnt->cl_auth->au_flavor == RPC_AUTH_GSS_KRB5I) ||
+ (clnt->cl_auth->au_flavor == RPC_AUTH_GSS_KRB5P)) {
+ cr = rpcauth_lookup_credcache(clnt->cl_auth, &ac, 0);
+ if (IS_ERR(cr) || cr == NULL)
+ continue;
+ dprintk("%s invalidated cred %p from auth %p crcache\n",
+ __func__, cr, clnt->cl_auth);
+ smp_mb__before_clear_bit();
+ clear_bit(RPCAUTH_CRED_UPTODATE, &cr->cr_flags);
+ smp_mb__after_clear_bit();
+ put_rpccred(cr); /* balance get in lookup credcache */
+ }
+ }
+ spin_unlock(&sn->rpc_client_lock);
+}
+
+static void
+gss_user_destroy(struct key *key)
+{
+ struct user_key_payload *upayload;
+ int uid = 0;
+
+ upayload = rcu_dereference_key(key);
+ memcpy((void *)&uid, upayload->data, sizeof(int));
+ gss_kdestroy_cred((uid_t)uid);
+ return user_destroy(key);
+}
+
+static struct key_type key_type_gss_ctx = {
+ .name = "gss-ctx",
+ .instantiate = user_instantiate,
+ .match = user_match,
+ .revoke = user_revoke,
+ .destroy = gss_user_destroy,
+ .describe = user_describe,
+ .read = user_read,
+};
+
+
+/* Register the gss-ctx key type for use by nfslogin and nfslogout */
+static int gss_register_ctx_keytype(void)
+{
+ int ret;
+
+ ret = register_key_type(&key_type_gss_ctx);
+
+ pr_notice("NFS: Registering the %s key type ret %d\n",
+ key_type_gss_ctx.name, ret);
+
+ return ret;
+}
+
+static void gss_unregister_ctx_keytype(void)
+{
+ unregister_key_type(&key_type_gss_ctx);
+}
+
static inline struct gss_cl_ctx *
gss_get_ctx(struct gss_cl_ctx *ctx)
{
@@ -1748,6 +1831,7 @@ static int __init init_rpcsec_gss(void)
if (err)
goto out_svc_exit;
rpc_init_wait_queue(&pipe_version_rpc_waitqueue, "gss pipe version");
+ gss_register_ctx_keytype();
return 0;
out_svc_exit:
gss_svc_shutdown();
@@ -1762,6 +1846,7 @@ static void __exit exit_rpcsec_gss(void)
unregister_pernet_subsys(&rpcsec_gss_net_ops);
gss_svc_shutdown();
rpcauth_unregister(&authgss_ops);
+ gss_unregister_ctx_keytype();
rcu_barrier(); /* Wait for completion of call_rcu()'s */
}
--
1.7.7.6
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH 1/1] SUNRPC: new keyring key_type for gss context destruction at kdestroy
2012-12-03 18:45 ` [PATCH 1/1] SUNRPC: new keyring key_type for gss context destruction at kdestroy andros
@ 2012-12-03 21:06 ` Myklebust, Trond
2012-12-03 22:39 ` Adamson, Andy
0 siblings, 1 reply; 7+ messages in thread
From: Myklebust, Trond @ 2012-12-03 21:06 UTC (permalink / raw)
To: Adamson, Andy; +Cc: linux-nfs
T24gTW9uLCAyMDEyLTEyLTAzIGF0IDEzOjQ1IC0wNTAwLCBhbmRyb3NAbmV0YXBwLmNvbSB3cm90
ZToNCj4gRnJvbTogQW5keSBBZGFtc29uIDxhbmRyb3NAbmV0YXBwLmNvbT4NCj4gDQo+IFRoaXMg
Y29kZSB3b3JrcyBpbiBjb25qdW5jdGlvbiB3aXRoIG5mc2xvZ2luIGFuZCBuZnNsb2dvdXQgcHJv
Z3JhbXMNCj4gd2hpY2ggZW5mb3JjZSB0aGUgdXNlIG9mIHRoZSBrZXlyaW5nIEtlcmJlcm9zIGNy
ZWRlbnRpYWwgY2FjaGUgb2YgdGhlDQo+IGZvcm0gS0VZUklORzprcmI1Y2NfPFVJRD4gYW5kIGFk
ZHMgYSBnc3MtY3R4IGtleSB0byB0aGUga3JiNWNjXzxVSUQ+IGtleXJpbmcuDQo+IA0KPiBXaGVu
IGtkZXN0cm95IGlzIGNhbGxlZCBvbiB0aGUga2V5cmluZyBjb250ZXh0IHRoZSAuZGVzdHJveSBm
dW5jdGlvbiBvZiB0aGUNCj4gbmV3IGtleSBpcyBjYWxsZWQgd2hpY2ggbWFya3MgYWxsIGdzc19j
b250ZXh0J3MgYXNzb2NpYXRlZCB3aXRoIHRoZSBVSUQgYXMNCj4gb3V0IG9mIGRhdGUuDQo+IA0K
PiBTaWduZWQtb2ZmLWJ5OiBBbmR5IEFkYW1zb24gPGFuZHJvc0BuZXRhcHAuY29tPg0KPiAtLS0N
Cj4gIG5ldC9zdW5ycGMvYXV0aF9nc3MvYXV0aF9nc3MuYyB8ICAgODUgKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKw0KPiAgMSBmaWxlcyBjaGFuZ2VkLCA4NSBpbnNlcnRp
b25zKCspLCAwIGRlbGV0aW9ucygtKQ0KPiANCj4gZGlmZiAtLWdpdCBhL25ldC9zdW5ycGMvYXV0
aF9nc3MvYXV0aF9nc3MuYyBiL25ldC9zdW5ycGMvYXV0aF9nc3MvYXV0aF9nc3MuYw0KPiBpbmRl
eCAwODJlNTc5Li4yZDhmYmYxIDEwMDY0NA0KPiAtLS0gYS9uZXQvc3VucnBjL2F1dGhfZ3NzL2F1
dGhfZ3NzLmMNCj4gKysrIGIvbmV0L3N1bnJwYy9hdXRoX2dzcy9hdXRoX2dzcy5jDQo+IEBAIC01
MSw2ICs1MSwxMiBAQA0KPiAgI2luY2x1ZGUgPGxpbnV4L3N1bnJwYy9ycGNfcGlwZV9mcy5oPg0K
PiAgI2luY2x1ZGUgPGxpbnV4L3N1bnJwYy9nc3NfYXBpLmg+DQo+ICAjaW5jbHVkZSA8YXNtL3Vh
Y2Nlc3MuaD4NCj4gKyNpbmNsdWRlIDxsaW51eC9rZXkuaD4NCj4gKyNpbmNsdWRlIDxsaW51eC9r
ZXljdGwuaD4NCj4gKyNpbmNsdWRlIDxsaW51eC9rZXktdHlwZS5oPg0KPiArI2luY2x1ZGUgPGtl
eXMvdXNlci10eXBlLmg+DQo+ICsNCj4gKyNpbmNsdWRlICIuLi9uZXRucy5oIg0KPiAgDQo+ICBz
dGF0aWMgY29uc3Qgc3RydWN0IHJwY19hdXRob3BzIGF1dGhnc3Nfb3BzOw0KPiAgDQo+IEBAIC05
NSw2ICsxMDEsODMgQEAgc3RhdGljIHZvaWQgZ3NzX2ZyZWVfY3R4KHN0cnVjdCBnc3NfY2xfY3R4
ICopOw0KPiAgc3RhdGljIGNvbnN0IHN0cnVjdCBycGNfcGlwZV9vcHMgZ3NzX3VwY2FsbF9vcHNf
djA7DQo+ICBzdGF0aWMgY29uc3Qgc3RydWN0IHJwY19waXBlX29wcyBnc3NfdXBjYWxsX29wc192
MTsNCj4gIA0KPiArLyoNCj4gKyAqIFNlYXJjaCBhbGwgcnBjX2NsbnQgYXV0aCdzIGFuZCBpbnZh
bGlkYXRlIGFueSBSUENfQVVUX0dTUyBLZXJiZXJvcw0KPiArICogZ3NzIGNvbnRleHRzIGJlbG9u
Z2luZyB0byB1aWQuIFRyaWdnZXJlZCBieSBrZGVzdHJveSBvZiBrZXlyaW5nDQo+ICsgKiBrZXJi
ZXJvcyBjcmVkZW50aWFscy4NCj4gKyAqLw0KPiArc3RhdGljIHZvaWQNCj4gK2dzc19rZGVzdHJv
eV9jcmVkKHVpZF90IHVpZCkNCj4gK3sNCj4gKwlzdHJ1Y3QgbmV0ICpuZXQgPSBjdXJyZW50LT5u
c3Byb3h5LT5uZXRfbnM7DQo+ICsJc3RydWN0IHN1bnJwY19uZXQgKnNuID0gbmV0X2dlbmVyaWMo
bmV0LCBzdW5ycGNfbmV0X2lkKTsNCj4gKwlzdHJ1Y3QgcnBjX2NsbnQgKmNsbnQ7DQo+ICsJc3Ry
dWN0IHJwY19jcmVkICpjcjsNCj4gKwlzdHJ1Y3QgYXV0aF9jcmVkIGFjID0gew0KPiArCQkudWlk
ID0gdWlkLA0KPiArCX07DQo+ICsNCj4gKwlkcHJpbnRrKCItLT4gJXMgdWlkICVkXG4iLCBfX2Z1
bmNfXywgdWlkKTsNCj4gKwlzcGluX2xvY2soJnNuLT5ycGNfY2xpZW50X2xvY2spOw0KPiArCWxp
c3RfZm9yX2VhY2hfZW50cnkoY2xudCwgJnNuLT5hbGxfY2xpZW50cywgY2xfY2xpZW50cykgew0K
PiArCQlpZiAoKGNsbnQtPmNsX2F1dGgtPmF1X2ZsYXZvciA9PSBSUENfQVVUSF9HU1NfS1JCNSkg
fHwNCj4gKwkJICAgIChjbG50LT5jbF9hdXRoLT5hdV9mbGF2b3IgPT0gUlBDX0FVVEhfR1NTX0tS
QjVJKSB8fA0KPiArCQkgICAgKGNsbnQtPmNsX2F1dGgtPmF1X2ZsYXZvciA9PSBSUENfQVVUSF9H
U1NfS1JCNVApKSB7DQo+ICsJCQljciA9IHJwY2F1dGhfbG9va3VwX2NyZWRjYWNoZShjbG50LT5j
bF9hdXRoLCAmYWMsIDApOw0KPiArCQkJaWYgKElTX0VSUihjcikgfHwgY3IgPT0gTlVMTCkNCj4g
KwkJCQljb250aW51ZTsNCj4gKwkJCWRwcmludGsoIiVzIGludmFsaWRhdGVkIGNyZWQgJXAgZnJv
bSBhdXRoICVwIGNyY2FjaGVcbiIsDQo+ICsJCQkJIF9fZnVuY19fLCBjciwgY2xudC0+Y2xfYXV0
aCk7DQo+ICsJCQlzbXBfbWJfX2JlZm9yZV9jbGVhcl9iaXQoKTsNCj4gKwkJCWNsZWFyX2JpdChS
UENBVVRIX0NSRURfVVBUT0RBVEUsICZjci0+Y3JfZmxhZ3MpOw0KPiArCQkJc21wX21iX19hZnRl
cl9jbGVhcl9iaXQoKTsNCj4gKwkJCXB1dF9ycGNjcmVkKGNyKTsgLyogYmFsYW5jZSBnZXQgaW4g
bG9va3VwIGNyZWRjYWNoZSAqLw0KPiArCQl9DQo+ICsJfQ0KPiArCXNwaW5fdW5sb2NrKCZzbi0+
cnBjX2NsaWVudF9sb2NrKTsNCj4gK30NCj4gKw0KPiArc3RhdGljIHZvaWQNCj4gK2dzc191c2Vy
X2Rlc3Ryb3koc3RydWN0IGtleSAqa2V5KQ0KPiArew0KPiArCXN0cnVjdCB1c2VyX2tleV9wYXls
b2FkICp1cGF5bG9hZDsNCj4gKwlpbnQgdWlkID0gMDsNCj4gKw0KPiArCXVwYXlsb2FkID0gcmN1
X2RlcmVmZXJlbmNlX2tleShrZXkpOw0KPiArCW1lbWNweSgodm9pZCAqKSZ1aWQsIHVwYXlsb2Fk
LT5kYXRhLCBzaXplb2YoaW50KSk7DQoNCkl0IHNlZW1zIHRvIG1lIHRoYXQgdGhpcyBjb2RlIGFs
bG93cyBtZSB0byBraWxsIGFueW9uZSdzIHJwY3NlY19nc3MNCnNlc3Npb25zIGJ5IGNyZWF0aW5n
IGEga2V5IHdpdGggdGhlaXIgdWlkLCBhbmQgdGhlbiBkZXN0cm95aW5nIGl0Lg0KDQpPbmUgc29s
dXRpb24gaXMgdG8gcmVwbGFjZSB1c2VyX2luc3RhbnRpYXRlKCkgd2l0aCBzb21ldGhpbmcgdGhh
dCBzZXRzDQp0aGUgcGF5bG9hZCB0byBhIHZhbHVlIGRldGVybWluZWQgYnkgdGhlIGtlcm5lbCBp
dHNlbGYuIFdlJ2QgZGVmaW5pdGVseQ0Kd2FudCB0byBpbmNsdWRlIHRoZSB1aWQsIGJ1dCBwZXJo
YXBzIGFsc28gYWRkIGEgY29va2llIHRoYXQgaXMgdW5pcXVlIHRvDQp0aGlzIGtleSAodXNpbmcg
dGhlIGlkci9pZGEgc3R1ZmYgZnJvbSBpbmNsdWRlL2xpbnV4L2lkci5oID8pLCBhbmQgdGhhdA0K
Y2FuIGJlIHVzZWQgdG8gZGlzdGluZ3Vpc2ggaXQgZnJvbSBrZXlzIGdlbmVyYXRlZCBmcm9tIG90
aGVyIHByb2Nlc3Nlcy4NCklmIHdlIHdlcmUgdG8gdXNlIHRoZSBzYW1lIGtleSB0byBsYWJlbCB0
aGUgYXV0aF9nc3MgY3JlZHMsIHRoZW4gd2UNCmNvdWxkIGhhdmUgdXNlcl9nc3NfZGVzdHJveSgp
IGtpbGwgX29ubHlfIHRoZSBhdXRoX2dzcyBjcmVkcyB0aGF0IGl0DQpzcGF3bmVkLg0KDQpVbHRp
bWF0ZWx5LCB0aG91Z2gsIEkgdGhpbmsgd2UgbWlnaHQgd2FudCB0byBsZXQgdGhlIHVzZXIgc2V0
IGF0IGxlYXN0DQpfcGFydF8gb2YgdGhlIHBheWxvYWQgdG8gc29tZXRoaW5nIHRoYXQgbWlnaHQg
YmUgdXNlZnVsIHRvIGdzc2Qgd2hlbiBpdA0KZ29lcyBsb29raW5nIGZvciBjcmVkZW50aWFscy4g
U2luY2UgdGhlIG5mc2xvZ2luIGFuZCBnc3NkIHdpbGwgYmUNCnNoaXBwZWQgYXMgcGFydCBvZiB0
aGUgbmZzLXV0aWxzIHBhY2thZ2UsIGl0IHdvdWxkIGJlIG5pY2UgdG8gYWxsb3cgdGhlbQ0KdG8g
dXNlIHRoZSBnc3MtY3R4IGtleSBpbiBvcmRlciB0byBjb21tdW5pY2F0ZS4gSW50ZXJlc3Rpbmcg
aW5mb3JtYXRpb24NCm1pZ2h0IGluY2x1ZGUgdGhlIEtSQjVDQ05BTUUuDQoNCj4gKwlnc3Nfa2Rl
c3Ryb3lfY3JlZCgodWlkX3QpdWlkKTsNCj4gKwlyZXR1cm4gdXNlcl9kZXN0cm95KGtleSk7DQo+
ICt9DQo+ICsNCj4gK3N0YXRpYyBzdHJ1Y3Qga2V5X3R5cGUga2V5X3R5cGVfZ3NzX2N0eCA9IHsN
Cj4gKwkubmFtZQkJPSAiZ3NzLWN0eCIsDQo+ICsJLmluc3RhbnRpYXRlCT0gdXNlcl9pbnN0YW50
aWF0ZSwNCj4gKwkubWF0Y2gJCT0gdXNlcl9tYXRjaCwNCj4gKwkucmV2b2tlCQk9IHVzZXJfcmV2
b2tlLA0KPiArCS5kZXN0cm95CT0gZ3NzX3VzZXJfZGVzdHJveSwNCj4gKwkuZGVzY3JpYmUJPSB1
c2VyX2Rlc2NyaWJlLA0KPiArCS5yZWFkCQk9IHVzZXJfcmVhZCwNCj4gK307DQo+ICsNCj4gKw0K
PiArLyogUmVnaXN0ZXIgdGhlIGdzcy1jdHgga2V5IHR5cGUgZm9yIHVzZSBieSBuZnNsb2dpbiBh
bmQgbmZzbG9nb3V0ICovDQo+ICtzdGF0aWMgaW50IGdzc19yZWdpc3Rlcl9jdHhfa2V5dHlwZSh2
b2lkKQ0KPiArew0KPiArCWludCByZXQ7DQo+ICsNCj4gKwlyZXQgPSByZWdpc3Rlcl9rZXlfdHlw
ZSgma2V5X3R5cGVfZ3NzX2N0eCk7DQo+ICsNCj4gKwlwcl9ub3RpY2UoIk5GUzogUmVnaXN0ZXJp
bmcgdGhlICVzIGtleSB0eXBlIHJldCAlZFxuIiwNCj4gKwkJa2V5X3R5cGVfZ3NzX2N0eC5uYW1l
LCByZXQpOw0KPiArDQo+ICsJcmV0dXJuIHJldDsNCj4gK30NCj4gKw0KPiArc3RhdGljIHZvaWQg
Z3NzX3VucmVnaXN0ZXJfY3R4X2tleXR5cGUodm9pZCkNCj4gK3sNCj4gKwl1bnJlZ2lzdGVyX2tl
eV90eXBlKCZrZXlfdHlwZV9nc3NfY3R4KTsNCj4gK30NCj4gKw0KPiAgc3RhdGljIGlubGluZSBz
dHJ1Y3QgZ3NzX2NsX2N0eCAqDQo+ICBnc3NfZ2V0X2N0eChzdHJ1Y3QgZ3NzX2NsX2N0eCAqY3R4
KQ0KPiAgew0KPiBAQCAtMTc0OCw2ICsxODMxLDcgQEAgc3RhdGljIGludCBfX2luaXQgaW5pdF9y
cGNzZWNfZ3NzKHZvaWQpDQo+ICAJaWYgKGVycikNCj4gIAkJZ290byBvdXRfc3ZjX2V4aXQ7DQo+
ICAJcnBjX2luaXRfd2FpdF9xdWV1ZSgmcGlwZV92ZXJzaW9uX3JwY193YWl0cXVldWUsICJnc3Mg
cGlwZSB2ZXJzaW9uIik7DQo+ICsJZ3NzX3JlZ2lzdGVyX2N0eF9rZXl0eXBlKCk7DQo+ICAJcmV0
dXJuIDA7DQo+ICBvdXRfc3ZjX2V4aXQ6DQo+ICAJZ3NzX3N2Y19zaHV0ZG93bigpOw0KPiBAQCAt
MTc2Miw2ICsxODQ2LDcgQEAgc3RhdGljIHZvaWQgX19leGl0IGV4aXRfcnBjc2VjX2dzcyh2b2lk
KQ0KPiAgCXVucmVnaXN0ZXJfcGVybmV0X3N1YnN5cygmcnBjc2VjX2dzc19uZXRfb3BzKTsNCj4g
IAlnc3Nfc3ZjX3NodXRkb3duKCk7DQo+ICAJcnBjYXV0aF91bnJlZ2lzdGVyKCZhdXRoZ3NzX29w
cyk7DQo+ICsJZ3NzX3VucmVnaXN0ZXJfY3R4X2tleXR5cGUoKTsNCj4gIAlyY3VfYmFycmllcigp
OyAvKiBXYWl0IGZvciBjb21wbGV0aW9uIG9mIGNhbGxfcmN1KCkncyAqLw0KPiAgfQ0KPiAgDQoN
Ci0tIA0KVHJvbmQgTXlrbGVidXN0DQpMaW51eCBORlMgY2xpZW50IG1haW50YWluZXINCg0KTmV0
QXBwDQpUcm9uZC5NeWtsZWJ1c3RAbmV0YXBwLmNvbQ0Kd3d3Lm5ldGFwcC5jb20NCg==
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/1] SUNRPC: new keyring key_type for gss context destruction at kdestroy
2012-12-03 21:06 ` Myklebust, Trond
@ 2012-12-03 22:39 ` Adamson, Andy
2012-12-04 14:56 ` Myklebust, Trond
0 siblings, 1 reply; 7+ messages in thread
From: Adamson, Andy @ 2012-12-03 22:39 UTC (permalink / raw)
To: Myklebust, Trond; +Cc: Adamson, Andy, linux-nfs
On Dec 3, 2012, at 4:06 PM, "Myklebust, Trond" <Trond.Myklebust@netapp.com>
wrote:
> On Mon, 2012-12-03 at 13:45 -0500, andros@netapp.com wrote:
>> From: Andy Adamson <andros@netapp.com>
>>
>> This code works in conjunction with nfslogin and nfslogout programs
>> which enforce the use of the keyring Kerberos credential cache of the
>> form KEYRING:krb5cc_<UID> and adds a gss-ctx key to the krb5cc_<UID> keyring.
>>
>> When kdestroy is called on the keyring context the .destroy function of the
>> new key is called which marks all gss_context's associated with the UID as
>> out of date.
>>
>> Signed-off-by: Andy Adamson <andros@netapp.com>
>> ---
>> net/sunrpc/auth_gss/auth_gss.c | 85 ++++++++++++++++++++++++++++++++++++++++
>> 1 files changed, 85 insertions(+), 0 deletions(-)
>>
>> diff --git a/net/sunrpc/auth_gss/auth_gss.c b/net/sunrpc/auth_gss/auth_gss.c
>> index 082e579..2d8fbf1 100644
>> --- a/net/sunrpc/auth_gss/auth_gss.c
>> +++ b/net/sunrpc/auth_gss/auth_gss.c
>> @@ -51,6 +51,12 @@
>> #include <linux/sunrpc/rpc_pipe_fs.h>
>> #include <linux/sunrpc/gss_api.h>
>> #include <asm/uaccess.h>
>> +#include <linux/key.h>
>> +#include <linux/keyctl.h>
>> +#include <linux/key-type.h>
>> +#include <keys/user-type.h>
>> +
>> +#include "../netns.h"
>>
>> static const struct rpc_authops authgss_ops;
>>
>> @@ -95,6 +101,83 @@ static void gss_free_ctx(struct gss_cl_ctx *);
>> static const struct rpc_pipe_ops gss_upcall_ops_v0;
>> static const struct rpc_pipe_ops gss_upcall_ops_v1;
>>
>> +/*
>> + * Search all rpc_clnt auth's and invalidate any RPC_AUT_GSS Kerberos
>> + * gss contexts belonging to uid. Triggered by kdestroy of keyring
>> + * kerberos credentials.
>> + */
>> +static void
>> +gss_kdestroy_cred(uid_t uid)
>> +{
>> + struct net *net = current->nsproxy->net_ns;
>> + struct sunrpc_net *sn = net_generic(net, sunrpc_net_id);
>> + struct rpc_clnt *clnt;
>> + struct rpc_cred *cr;
>> + struct auth_cred ac = {
>> + .uid = uid,
>> + };
>> +
>> + dprintk("--> %s uid %d\n", __func__, uid);
>> + spin_lock(&sn->rpc_client_lock);
>> + list_for_each_entry(clnt, &sn->all_clients, cl_clients) {
>> + if ((clnt->cl_auth->au_flavor == RPC_AUTH_GSS_KRB5) ||
>> + (clnt->cl_auth->au_flavor == RPC_AUTH_GSS_KRB5I) ||
>> + (clnt->cl_auth->au_flavor == RPC_AUTH_GSS_KRB5P)) {
>> + cr = rpcauth_lookup_credcache(clnt->cl_auth, &ac, 0);
>> + if (IS_ERR(cr) || cr == NULL)
>> + continue;
>> + dprintk("%s invalidated cred %p from auth %p crcache\n",
>> + __func__, cr, clnt->cl_auth);
>> + smp_mb__before_clear_bit();
>> + clear_bit(RPCAUTH_CRED_UPTODATE, &cr->cr_flags);
>> + smp_mb__after_clear_bit();
>> + put_rpccred(cr); /* balance get in lookup credcache */
>> + }
>> + }
>> + spin_unlock(&sn->rpc_client_lock);
>> +}
>> +
>> +static void
>> +gss_user_destroy(struct key *key)
>> +{
>> + struct user_key_payload *upayload;
>> + int uid = 0;
>> +
>> + upayload = rcu_dereference_key(key);
>> + memcpy((void *)&uid, upayload->data, sizeof(int));
>
> It seems to me that this code allows me to kill anyone's rpcsec_gss
> sessions by creating a key with their uid, and then destroying it.
Yes - just proof of concept code. There is a lot to consider.
>
> One solution is to replace user_instantiate() with something that sets
> the payload to a value determined by the kernel itself. We'd definitely
> want to include the uid, but perhaps also add a cookie that is unique to
> this key (using the idr/ida stuff from include/linux/idr.h ?), and that
> can be used to distinguish it from keys generated from other processes.
> If we were to use the same key to label the auth_gss creds, then we
> could have user_gss_destroy() kill _only_ the auth_gss creds that it
> spawned.
Yes, killing only the auth it spawned is indeed what we want.
>
> Ultimately, though, I think we might want to let the user set at least
> _part_ of the payload to something that might be useful to gssd when it
> goes looking for credentials. Since the nfslogin and gssd will be
> shipped as part of the nfs-utils package, it would be nice to allow them
> to use the gss-ctx key in order to communicate. Interesting information
> might include the KRB5CCNAME.
Thanks for the good suggestions.
-->Andy
>
>> + gss_kdestroy_cred((uid_t)uid);
>> + return user_destroy(key);
>> +}
>> +
>> +static struct key_type key_type_gss_ctx = {
>> + .name = "gss-ctx",
>> + .instantiate = user_instantiate,
>> + .match = user_match,
>> + .revoke = user_revoke,
>> + .destroy = gss_user_destroy,
>> + .describe = user_describe,
>> + .read = user_read,
>> +};
>> +
>> +
>> +/* Register the gss-ctx key type for use by nfslogin and nfslogout */
>> +static int gss_register_ctx_keytype(void)
>> +{
>> + int ret;
>> +
>> + ret = register_key_type(&key_type_gss_ctx);
>> +
>> + pr_notice("NFS: Registering the %s key type ret %d\n",
>> + key_type_gss_ctx.name, ret);
>> +
>> + return ret;
>> +}
>> +
>> +static void gss_unregister_ctx_keytype(void)
>> +{
>> + unregister_key_type(&key_type_gss_ctx);
>> +}
>> +
>> static inline struct gss_cl_ctx *
>> gss_get_ctx(struct gss_cl_ctx *ctx)
>> {
>> @@ -1748,6 +1831,7 @@ static int __init init_rpcsec_gss(void)
>> if (err)
>> goto out_svc_exit;
>> rpc_init_wait_queue(&pipe_version_rpc_waitqueue, "gss pipe version");
>> + gss_register_ctx_keytype();
>> return 0;
>> out_svc_exit:
>> gss_svc_shutdown();
>> @@ -1762,6 +1846,7 @@ static void __exit exit_rpcsec_gss(void)
>> unregister_pernet_subsys(&rpcsec_gss_net_ops);
>> gss_svc_shutdown();
>> rpcauth_unregister(&authgss_ops);
>> + gss_unregister_ctx_keytype();
>> rcu_barrier(); /* Wait for completion of call_rcu()'s */
>> }
>>
>
> --
> Trond Myklebust
> Linux NFS client maintainer
>
> NetApp
> Trond.Myklebust@netapp.com
> www.netapp.com
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/1] SUNRPC: new keyring key_type for gss context destruction at kdestroy
2012-12-03 22:39 ` Adamson, Andy
@ 2012-12-04 14:56 ` Myklebust, Trond
2012-12-04 15:58 ` Adamson, Andy
0 siblings, 1 reply; 7+ messages in thread
From: Myklebust, Trond @ 2012-12-04 14:56 UTC (permalink / raw)
To: Adamson, Andy; +Cc: linux-nfs
T24gTW9uLCAyMDEyLTEyLTAzIGF0IDIyOjM5ICswMDAwLCBBZGFtc29uLCBBbmR5IHdyb3RlOg0K
PiBPbiBEZWMgMywgMjAxMiwgYXQgNDowNiBQTSwgIk15a2xlYnVzdCwgVHJvbmQiIDxUcm9uZC5N
eWtsZWJ1c3RAbmV0YXBwLmNvbT4NCj4gIHdyb3RlOg0KDQo+ID4gSXQgc2VlbXMgdG8gbWUgdGhh
dCB0aGlzIGNvZGUgYWxsb3dzIG1lIHRvIGtpbGwgYW55b25lJ3MgcnBjc2VjX2dzcw0KPiA+IHNl
c3Npb25zIGJ5IGNyZWF0aW5nIGEga2V5IHdpdGggdGhlaXIgdWlkLCBhbmQgdGhlbiBkZXN0cm95
aW5nIGl0Lg0KPiANCj4gWWVzIC0ganVzdCBwcm9vZiBvZiBjb25jZXB0IGNvZGUuIFRoZXJlIGlz
IGEgbG90IHRvIGNvbnNpZGVyLg0KPiANCj4gPiANCj4gPiBPbmUgc29sdXRpb24gaXMgdG8gcmVw
bGFjZSB1c2VyX2luc3RhbnRpYXRlKCkgd2l0aCBzb21ldGhpbmcgdGhhdCBzZXRzDQo+ID4gdGhl
IHBheWxvYWQgdG8gYSB2YWx1ZSBkZXRlcm1pbmVkIGJ5IHRoZSBrZXJuZWwgaXRzZWxmLiBXZSdk
IGRlZmluaXRlbHkNCj4gPiB3YW50IHRvIGluY2x1ZGUgdGhlIHVpZCwgYnV0IHBlcmhhcHMgYWxz
byBhZGQgYSBjb29raWUgdGhhdCBpcyB1bmlxdWUgdG8NCj4gPiB0aGlzIGtleSAodXNpbmcgdGhl
IGlkci9pZGEgc3R1ZmYgZnJvbSBpbmNsdWRlL2xpbnV4L2lkci5oID8pLCBhbmQgdGhhdA0KPiA+
IGNhbiBiZSB1c2VkIHRvIGRpc3Rpbmd1aXNoIGl0IGZyb20ga2V5cyBnZW5lcmF0ZWQgZnJvbSBv
dGhlciBwcm9jZXNzZXMuDQo+ID4gSWYgd2Ugd2VyZSB0byB1c2UgdGhlIHNhbWUga2V5IHRvIGxh
YmVsIHRoZSBhdXRoX2dzcyBjcmVkcywgdGhlbiB3ZQ0KPiA+IGNvdWxkIGhhdmUgdXNlcl9nc3Nf
ZGVzdHJveSgpIGtpbGwgX29ubHlfIHRoZSBhdXRoX2dzcyBjcmVkcyB0aGF0IGl0DQo+ID4gc3Bh
d25lZC4NCj4gDQo+IFllcywga2lsbGluZyBvbmx5IHRoZSBhdXRoIGl0IHNwYXduZWQgaXMgaW5k
ZWVkIHdoYXQgd2Ugd2FudC4NCj4gDQo+ID4gDQo+ID4gVWx0aW1hdGVseSwgdGhvdWdoLCBJIHRo
aW5rIHdlIG1pZ2h0IHdhbnQgdG8gbGV0IHRoZSB1c2VyIHNldCBhdCBsZWFzdA0KPiA+IF9wYXJ0
XyBvZiB0aGUgcGF5bG9hZCB0byBzb21ldGhpbmcgdGhhdCBtaWdodCBiZSB1c2VmdWwgdG8gZ3Nz
ZCB3aGVuIGl0DQo+ID4gZ29lcyBsb29raW5nIGZvciBjcmVkZW50aWFscy4gU2luY2UgdGhlIG5m
c2xvZ2luIGFuZCBnc3NkIHdpbGwgYmUNCj4gPiBzaGlwcGVkIGFzIHBhcnQgb2YgdGhlIG5mcy11
dGlscyBwYWNrYWdlLCBpdCB3b3VsZCBiZSBuaWNlIHRvIGFsbG93IHRoZW0NCj4gPiB0byB1c2Ug
dGhlIGdzcy1jdHgga2V5IGluIG9yZGVyIHRvIGNvbW11bmljYXRlLiBJbnRlcmVzdGluZyBpbmZv
cm1hdGlvbg0KPiA+IG1pZ2h0IGluY2x1ZGUgdGhlIEtSQjVDQ05BTUUuDQo+IA0KPiBUaGFua3Mg
Zm9yIHRoZSBnb29kIHN1Z2dlc3Rpb25zLg0KDQpTbywgSSd2ZSBnb3QgYSBxdWVzdGlvbjogQ2Fu
IHdlIHJlcGxhY2Ugc29tZSBvZiB0aGUgc3R1ZmYgaW4gdGhlICJSRkMNCkF2b2lkIGV4cGlyZWQg
Y3JlZGVudGlhbCBrZXlzIGZvciBidWZmZXJlZCB3cml0ZXMiIHBhdGNoIHNlcmllcyB3aXRoDQp0
aGlzPw0KDQpNeSB0aGlua2luZyBpcyB0aGF0IHNpbmNlIHRoZSB1c2VyX2dzc19kZXN0cm95KCkg
aGFzIHRvIHN5bmMgYWxsIGZpbGVzDQphbmQgdGhlbiBpbnZhbGlkYXRlIHRoZSBycGNzZWNfZ3Nz
IGNyZWRzLCB3ZSdyZSBwcmV0dHkgbXVjaCBkb2luZyB0aGUNCnNhbWUgdGhpbmcgYXMgaW4gdGhl
IGFib3ZlIFJGQyBwYXRjaCBzZXJpZXMuIElmIG5mc2xvZ2luIHdlcmUgdG8gdGVsbA0KdGhlIGdz
cy1jdHgga2V5IGhvdyBsb25nIHVudGlsIHRoZSBrZXJiZXJvcyB0Z3QgZXhwaXJlcywgY291bGRu
J3Qgd2UNCmhhdmUgYSB3b3JrIHF1ZXVlIGpvYiB3YWtlIHVwIGp1c3QgYmVmb3JlIHRoZSB0Z3Qg
aXMgYWJvdXQgdG8gZXhwaXJlLA0KYW5kIHNpbXBseSBjYWxsIHVzZXJfZ3NzX2Rlc3Ryb3kgYnkg
cmV2b2tpbmcgdGhlIGdzcy1jdHgga2V5Pw0KSWYsIG9uIHRoZSBvdGhlciBoYW5kLCB0aGUgdXNl
ciByZW5ld3MgdGhlIHRndCB1c2luZyBuZnNsb2dpbiwgdGhlbiB3ZQ0KY291bGQgdXBkYXRlIHRo
ZSBnc3MtY3R4IGtleSwgYW5kIGRlZmVyIHRoZSB3b3JrIHF1ZXVlIGpvYiB1bnRpbCB0aGUgbmV3
DQpleHBpcnQgdGltZS4NCg0KLS0gDQpUcm9uZCBNeWtsZWJ1c3QNCkxpbnV4IE5GUyBjbGllbnQg
bWFpbnRhaW5lcg0KDQpOZXRBcHANClRyb25kLk15a2xlYnVzdEBuZXRhcHAuY29tDQp3d3cubmV0
YXBwLmNvbQ0K
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/1] SUNRPC: new keyring key_type for gss context destruction at kdestroy
2012-12-04 14:56 ` Myklebust, Trond
@ 2012-12-04 15:58 ` Adamson, Andy
2012-12-04 16:04 ` Myklebust, Trond
0 siblings, 1 reply; 7+ messages in thread
From: Adamson, Andy @ 2012-12-04 15:58 UTC (permalink / raw)
To: Myklebust, Trond; +Cc: Adamson, Andy, linux-nfs
On Dec 4, 2012, at 9:56 AM, "Myklebust, Trond" <Trond.Myklebust@netapp.com>
wrote:
> On Mon, 2012-12-03 at 22:39 +0000, Adamson, Andy wrote:
>> On Dec 3, 2012, at 4:06 PM, "Myklebust, Trond" <Trond.Myklebust@netapp.com>
>> wrote:
>
>>> It seems to me that this code allows me to kill anyone's rpcsec_gss
>>> sessions by creating a key with their uid, and then destroying it.
>>
>> Yes - just proof of concept code. There is a lot to consider.
>>
>>>
>>> One solution is to replace user_instantiate() with something that sets
>>> the payload to a value determined by the kernel itself. We'd definitely
>>> want to include the uid, but perhaps also add a cookie that is unique to
>>> this key (using the idr/ida stuff from include/linux/idr.h ?), and that
>>> can be used to distinguish it from keys generated from other processes.
>>> If we were to use the same key to label the auth_gss creds, then we
>>> could have user_gss_destroy() kill _only_ the auth_gss creds that it
>>> spawned.
>>
>> Yes, killing only the auth it spawned is indeed what we want.
>>
>>>
>>> Ultimately, though, I think we might want to let the user set at least
>>> _part_ of the payload to something that might be useful to gssd when it
>>> goes looking for credentials. Since the nfslogin and gssd will be
>>> shipped as part of the nfs-utils package, it would be nice to allow them
>>> to use the gss-ctx key in order to communicate. Interesting information
>>> might include the KRB5CCNAME.
>>
>> Thanks for the good suggestions.
>
> So, I've got a question: Can we replace some of the stuff in the "RFC
> Avoid expired credential keys for buffered writes" patch series with
> this?
>
> My thinking is that since the user_gss_destroy() has to sync all files
> and then invalidate the rpcsec_gss creds, we're pretty much doing the
> same thing as in the above RFC patch series.
I was thinking the other way 'round. When gss_user_destroy gets called due to nfslogout (kdestroy) it triggers the RPC avoid expiration on buffered writes code with one difference: It does not allow _any_ new writes or _any_ other RPCs to use a GSS context with a valid lifetime but to be destroyed due to logout.
So instead of gss_user_destroy marking a GSS context as out of date, it will be marked as to be ONLY used for flushing writes that were buffered before the nfslogout (kdestroy) and associated commits.
> If nfslogin were to tell
> the gss-ctx key how long until the kerberos tgt expires,
We already have an expired time for the TGT in the GSS context downcall. Why do we need nfslogin to repeat the information? If you want to have a work queue job wake up based on the TGT lifetime, the info is already in the GSS context.
> couldn't we
> have a work queue job wake up just before the tgt is about to expire,
> and simply call user_gss_destroy by revoking the gss-ctx key?
I think using the TGT lifetime that existed to at the creation of the GSS context trigger the RPC avoid cred expiration code works really well. I don't see a need for a workqueue thread.
> If, on the other hand, the user renews the tgt using nfslogin,
Yes - this is in plan. nfslogin (e.g. TGT renewal) will update an existing gss-ctx key which in turn will trigger an upcall on associated GSS contexts to have them renewed. I didn't want to bother with this until the idea of nfslogin/nfslogout had been flown :)
> then we
> could update the gss-ctx key, and defer the work queue job until the new
> expirt time.
With nfslogin updating the GSS context, the same will happen with the current RPC avoid expired cred code.
-->Andy
>
> --
> Trond Myklebust
> Linux NFS client maintainer
>
> NetApp
> Trond.Myklebust@netapp.com
> www.netapp.com
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/1] SUNRPC: new keyring key_type for gss context destruction at kdestroy
2012-12-04 15:58 ` Adamson, Andy
@ 2012-12-04 16:04 ` Myklebust, Trond
0 siblings, 0 replies; 7+ messages in thread
From: Myklebust, Trond @ 2012-12-04 16:04 UTC (permalink / raw)
To: Adamson, Andy; +Cc: linux-nfs
T24gVHVlLCAyMDEyLTEyLTA0IGF0IDE1OjU4ICswMDAwLCBBZGFtc29uLCBBbmR5IHdyb3RlOg0K
PiBPbiBEZWMgNCwgMjAxMiwgYXQgOTo1NiBBTSwgIk15a2xlYnVzdCwgVHJvbmQiIDxUcm9uZC5N
eWtsZWJ1c3RAbmV0YXBwLmNvbT4NCj4gIHdyb3RlOg0KPiANCj4gPiBPbiBNb24sIDIwMTItMTIt
MDMgYXQgMjI6MzkgKzAwMDAsIEFkYW1zb24sIEFuZHkgd3JvdGU6DQo+ID4+IE9uIERlYyAzLCAy
MDEyLCBhdCA0OjA2IFBNLCAiTXlrbGVidXN0LCBUcm9uZCIgPFRyb25kLk15a2xlYnVzdEBuZXRh
cHAuY29tPg0KPiA+PiB3cm90ZToNCj4gPiANCj4gPj4+IEl0IHNlZW1zIHRvIG1lIHRoYXQgdGhp
cyBjb2RlIGFsbG93cyBtZSB0byBraWxsIGFueW9uZSdzIHJwY3NlY19nc3MNCj4gPj4+IHNlc3Np
b25zIGJ5IGNyZWF0aW5nIGEga2V5IHdpdGggdGhlaXIgdWlkLCBhbmQgdGhlbiBkZXN0cm95aW5n
IGl0Lg0KPiA+PiANCj4gPj4gWWVzIC0ganVzdCBwcm9vZiBvZiBjb25jZXB0IGNvZGUuIFRoZXJl
IGlzIGEgbG90IHRvIGNvbnNpZGVyLg0KPiA+PiANCj4gPj4+IA0KPiA+Pj4gT25lIHNvbHV0aW9u
IGlzIHRvIHJlcGxhY2UgdXNlcl9pbnN0YW50aWF0ZSgpIHdpdGggc29tZXRoaW5nIHRoYXQgc2V0
cw0KPiA+Pj4gdGhlIHBheWxvYWQgdG8gYSB2YWx1ZSBkZXRlcm1pbmVkIGJ5IHRoZSBrZXJuZWwg
aXRzZWxmLiBXZSdkIGRlZmluaXRlbHkNCj4gPj4+IHdhbnQgdG8gaW5jbHVkZSB0aGUgdWlkLCBi
dXQgcGVyaGFwcyBhbHNvIGFkZCBhIGNvb2tpZSB0aGF0IGlzIHVuaXF1ZSB0bw0KPiA+Pj4gdGhp
cyBrZXkgKHVzaW5nIHRoZSBpZHIvaWRhIHN0dWZmIGZyb20gaW5jbHVkZS9saW51eC9pZHIuaCA/
KSwgYW5kIHRoYXQNCj4gPj4+IGNhbiBiZSB1c2VkIHRvIGRpc3Rpbmd1aXNoIGl0IGZyb20ga2V5
cyBnZW5lcmF0ZWQgZnJvbSBvdGhlciBwcm9jZXNzZXMuDQo+ID4+PiBJZiB3ZSB3ZXJlIHRvIHVz
ZSB0aGUgc2FtZSBrZXkgdG8gbGFiZWwgdGhlIGF1dGhfZ3NzIGNyZWRzLCB0aGVuIHdlDQo+ID4+
PiBjb3VsZCBoYXZlIHVzZXJfZ3NzX2Rlc3Ryb3koKSBraWxsIF9vbmx5XyB0aGUgYXV0aF9nc3Mg
Y3JlZHMgdGhhdCBpdA0KPiA+Pj4gc3Bhd25lZC4NCj4gPj4gDQo+ID4+IFllcywga2lsbGluZyBv
bmx5IHRoZSBhdXRoIGl0IHNwYXduZWQgaXMgaW5kZWVkIHdoYXQgd2Ugd2FudC4NCj4gPj4gDQo+
ID4+PiANCj4gPj4+IFVsdGltYXRlbHksIHRob3VnaCwgSSB0aGluayB3ZSBtaWdodCB3YW50IHRv
IGxldCB0aGUgdXNlciBzZXQgYXQgbGVhc3QNCj4gPj4+IF9wYXJ0XyBvZiB0aGUgcGF5bG9hZCB0
byBzb21ldGhpbmcgdGhhdCBtaWdodCBiZSB1c2VmdWwgdG8gZ3NzZCB3aGVuIGl0DQo+ID4+PiBn
b2VzIGxvb2tpbmcgZm9yIGNyZWRlbnRpYWxzLiBTaW5jZSB0aGUgbmZzbG9naW4gYW5kIGdzc2Qg
d2lsbCBiZQ0KPiA+Pj4gc2hpcHBlZCBhcyBwYXJ0IG9mIHRoZSBuZnMtdXRpbHMgcGFja2FnZSwg
aXQgd291bGQgYmUgbmljZSB0byBhbGxvdyB0aGVtDQo+ID4+PiB0byB1c2UgdGhlIGdzcy1jdHgg
a2V5IGluIG9yZGVyIHRvIGNvbW11bmljYXRlLiBJbnRlcmVzdGluZyBpbmZvcm1hdGlvbg0KPiA+
Pj4gbWlnaHQgaW5jbHVkZSB0aGUgS1JCNUNDTkFNRS4NCj4gPj4gDQo+ID4+IFRoYW5rcyBmb3Ig
dGhlIGdvb2Qgc3VnZ2VzdGlvbnMuDQo+ID4gDQo+ID4gU28sIEkndmUgZ290IGEgcXVlc3Rpb246
IENhbiB3ZSByZXBsYWNlIHNvbWUgb2YgdGhlIHN0dWZmIGluIHRoZSAiUkZDDQo+ID4gQXZvaWQg
ZXhwaXJlZCBjcmVkZW50aWFsIGtleXMgZm9yIGJ1ZmZlcmVkIHdyaXRlcyIgcGF0Y2ggc2VyaWVz
IHdpdGgNCj4gPiB0aGlzPw0KPiA+IA0KPiA+IE15IHRoaW5raW5nIGlzIHRoYXQgc2luY2UgdGhl
IHVzZXJfZ3NzX2Rlc3Ryb3koKSBoYXMgdG8gc3luYyBhbGwgZmlsZXMNCj4gPiBhbmQgdGhlbiBp
bnZhbGlkYXRlIHRoZSBycGNzZWNfZ3NzIGNyZWRzLCB3ZSdyZSBwcmV0dHkgbXVjaCBkb2luZyB0
aGUNCj4gPiBzYW1lIHRoaW5nIGFzIGluIHRoZSBhYm92ZSBSRkMgcGF0Y2ggc2VyaWVzLg0KPiAN
Cj4gSSB3YXMgdGhpbmtpbmcgdGhlIG90aGVyIHdheSAncm91bmQuIFdoZW4gZ3NzX3VzZXJfZGVz
dHJveSBnZXRzIGNhbGxlZCBkdWUgdG8gbmZzbG9nb3V0IChrZGVzdHJveSkgaXQgdHJpZ2dlcnMg
dGhlIFJQQyBhdm9pZCBleHBpcmF0aW9uIG9uIGJ1ZmZlcmVkIHdyaXRlcyBjb2RlIHdpdGggb25l
IGRpZmZlcmVuY2U6IEl0IGRvZXMgbm90IGFsbG93IF9hbnlfIG5ldyB3cml0ZXMgb3IgX2FueV8g
b3RoZXIgUlBDcyB0byB1c2UgYSBHU1MgY29udGV4dCAgd2l0aCBhIHZhbGlkIGxpZmV0aW1lIGJ1
dCB0byBiZSBkZXN0cm95ZWQgZHVlIHRvIGxvZ291dC4gDQo+IA0KPiBTbyBpbnN0ZWFkIG9mIGdz
c191c2VyX2Rlc3Ryb3kgbWFya2luZyBhIEdTUyBjb250ZXh0IGFzIG91dCBvZiBkYXRlLCBpdCB3
aWxsIGJlIG1hcmtlZCBhcyB0byBiZSBPTkxZIHVzZWQgZm9yIGZsdXNoaW5nIHdyaXRlcyB0aGF0
IHdlcmUgYnVmZmVyZWQgYmVmb3JlIHRoZSBuZnNsb2dvdXQgKGtkZXN0cm95KSBhbmQgYXNzb2Np
YXRlZCBjb21taXRzLg0KPiANCj4gPiBJZiBuZnNsb2dpbiB3ZXJlIHRvIHRlbGwNCj4gPiB0aGUg
Z3NzLWN0eCBrZXkgaG93IGxvbmcgdW50aWwgdGhlIGtlcmJlcm9zIHRndCBleHBpcmVzLA0KPiAN
Cj4gV2UgYWxyZWFkeSBoYXZlIGFuIGV4cGlyZWQgdGltZSBmb3IgdGhlIFRHVCBpbiB0aGUgR1NT
IGNvbnRleHQgZG93bmNhbGwuIFdoeSBkbyB3ZSBuZWVkIG5mc2xvZ2luIHRvIHJlcGVhdCB0aGUg
aW5mb3JtYXRpb24/IElmIHlvdSB3YW50IHRvIGhhdmUgYSB3b3JrIHF1ZXVlIGpvYiB3YWtlIHVw
IGJhc2VkIG9uIHRoZSBUR1QgbGlmZXRpbWUsIHRoZSBpbmZvIGlzIGFscmVhZHkgaW4gdGhlIEdT
UyBjb250ZXh0Lg0KDQpGb3IgZGVhbGluZyB3aXRoIHRndCByZW5ld2Fscy4gVGhlIEdTUyBjb250
ZXh0IG9ubHkgY29udGFpbnMgdGhlIGV4cGlyZQ0KdGltZSB0aGF0IHdhcyBrbm93biB3aGVuIHRo
ZSBjb250ZXh0IHdhcyBjcmVhdGVkLiBJdCBkb2Vzbid0IGtub3csIGFuZA0KY2FuJ3QgdHJhY2sg
d2hldGhlciBvciBub3QgdGhlIHVzZXIgcmVuZXdlZCB0aGUgdGd0Lg0KDQo+ID4gY291bGRuJ3Qg
d2UNCj4gPiBoYXZlIGEgd29yayBxdWV1ZSBqb2Igd2FrZSB1cCBqdXN0IGJlZm9yZSB0aGUgdGd0
IGlzIGFib3V0IHRvIGV4cGlyZSwNCj4gPiBhbmQgc2ltcGx5IGNhbGwgdXNlcl9nc3NfZGVzdHJv
eSBieSByZXZva2luZyB0aGUgZ3NzLWN0eCBrZXk/DQo+IA0KPiBJIHRoaW5rIHVzaW5nICB0aGUg
VEdUIGxpZmV0aW1lIHRoYXQgZXhpc3RlZCB0byBhdCB0aGUgY3JlYXRpb24gb2YgdGhlIEdTUyBj
b250ZXh0IHRyaWdnZXIgdGhlIFJQQyBhdm9pZCBjcmVkIGV4cGlyYXRpb24gY29kZSB3b3JrcyBy
ZWFsbHkgd2VsbC4gSSBkb24ndCBzZWUgYSBuZWVkIGZvciBhIHdvcmtxdWV1ZSB0aHJlYWQuDQo+
IA0KPiA+IElmLCBvbiB0aGUgb3RoZXIgaGFuZCwgdGhlIHVzZXIgcmVuZXdzIHRoZSB0Z3QgdXNp
bmcgbmZzbG9naW4sDQo+IA0KPiBZZXMgLSB0aGlzIGlzIGluIHBsYW4uIG5mc2xvZ2luIChlLmcu
IFRHVCByZW5ld2FsKSB3aWxsIHVwZGF0ZSBhbiBleGlzdGluZyBnc3MtY3R4IGtleSB3aGljaCBp
biB0dXJuIHdpbGwgdHJpZ2dlciBhbiB1cGNhbGwgb24gYXNzb2NpYXRlZCBHU1MgY29udGV4dHMg
dG8gaGF2ZSB0aGVtIHJlbmV3ZWQuICBJIGRpZG4ndCB3YW50IHRvIGJvdGhlciB3aXRoIHRoaXMg
dW50aWwgdGhlIGlkZWEgb2YgbmZzbG9naW4vbmZzbG9nb3V0IGhhZCBiZWVuIGZsb3duIDopDQo+
IA0KPiA+IHRoZW4gd2UNCj4gPiBjb3VsZCB1cGRhdGUgdGhlIGdzcy1jdHgga2V5LCBhbmQgZGVm
ZXIgdGhlIHdvcmsgcXVldWUgam9iIHVudGlsIHRoZSBuZXcNCj4gPiBleHBpcnQgdGltZS4NCj4g
DQo+IFdpdGggbmZzbG9naW4gdXBkYXRpbmcgdGhlIEdTUyBjb250ZXh0LCB0aGUgc2FtZSB3aWxs
IGhhcHBlbiB3aXRoIHRoZSBjdXJyZW50IFJQQyBhdm9pZCBleHBpcmVkIGNyZWQgY29kZS4NCj4g
DQo+IC0tPkFuZHkNCj4gDQo+ID4gDQo+ID4gLS0gDQo+ID4gVHJvbmQgTXlrbGVidXN0DQo+ID4g
TGludXggTkZTIGNsaWVudCBtYWludGFpbmVyDQo+ID4gDQo+ID4gTmV0QXBwDQo+ID4gVHJvbmQu
TXlrbGVidXN0QG5ldGFwcC5jb20NCj4gPiB3d3cubmV0YXBwLmNvbQ0KPiANCg0KLS0gDQpUcm9u
ZCBNeWtsZWJ1c3QNCkxpbnV4IE5GUyBjbGllbnQgbWFpbnRhaW5lcg0KDQpOZXRBcHANClRyb25k
Lk15a2xlYnVzdEBuZXRhcHAuY29tDQp3d3cubmV0YXBwLmNvbQ0K
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-12-04 16:04 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-12-03 18:45 [PATCH 0/1] RFC: enable the use of the KEYRING credential cache andros
2012-12-03 18:45 ` [PATCH 1/1] SUNRPC: new keyring key_type for gss context destruction at kdestroy andros
2012-12-03 21:06 ` Myklebust, Trond
2012-12-03 22:39 ` Adamson, Andy
2012-12-04 14:56 ` Myklebust, Trond
2012-12-04 15:58 ` Adamson, Andy
2012-12-04 16:04 ` Myklebust, Trond
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.