We had a user report that for an export shared with sec=krb5*, any
changes in user credentials(ex: add user to a secondary group) take some
time before they take effect over the NFS share.
The problem was determined to be caused by the svcgssd process caching
the user credentials. The user credentials were initially cached for an
unlimited amount of time. There was some improvement in this behaviour
with the commit
svcgssd: use the actual context expiration for cache
commit eb3a145789b9eedd39b56e1d76f412435abaa747
The cache expiration time is now set to the time for which the kerberos
ticket is valid. However this is still considered too long. The proposed
solution is to allow administrators to explicitly set a timeout for
which the cache is valid. This is similar to changes which went into
gssd, the corresponding client side program.
The patch adds a -t <timeout> option to rpc.svcgssd so that the server's
administrator can specify an expiry timeout for the cached context.
After this timeout, an upcall is made to obtain the new user
credentials.
The default, timeout 0 results in the old behaviour.
Signed-off-bye: Sachin Prabhu <[email protected]>
diff --git a/utils/gssd/svcgssd.c b/utils/gssd/svcgssd.c
index 1afff9e..db99ea3 100644
--- a/utils/gssd/svcgssd.c
+++ b/utils/gssd/svcgssd.c
@@ -70,6 +70,8 @@
*/
int pipefds[2] = { -1, -1};
+unsigned int context_timeout = 0;
+
static void
mydaemon(int nochdir, int noclose)
{
@@ -167,7 +169,7 @@ sig_hup(int signal)
static void
usage(char *progname)
{
- fprintf(stderr, "usage: %s [-n] [-f] [-v] [-r] [-i] [-p principal]\n",
+ fprintf(stderr, "usage: %s [-n] [-f] [-v] [-r] [-i] [-p principal] [-t timeout]\n",
progname);
exit(1);
}
@@ -185,7 +187,7 @@ main(int argc, char *argv[])
char *progname;
char *principal = NULL;
- while ((opt = getopt(argc, argv, "fivrnp:")) != -1) {
+ while ((opt = getopt(argc, argv, "fivrnp:t:")) != -1) {
switch (opt) {
case 'f':
fg = 1;
@@ -205,6 +207,9 @@ main(int argc, char *argv[])
case 'p':
principal = optarg;
break;
+ case 't':
+ context_timeout = atoi(optarg);
+ break;
default:
usage(argv[0]);
break;
diff --git a/utils/gssd/svcgssd.h b/utils/gssd/svcgssd.h
index 9a2e2e8..869fb63 100644
--- a/utils/gssd/svcgssd.h
+++ b/utils/gssd/svcgssd.h
@@ -40,4 +40,6 @@ void gssd_run(void);
#define GSSD_SERVICE_NAME "nfs"
+extern unsigned int context_timeout;
+
#endif /* _RPC_SVCGSSD_H_ */
diff --git a/utils/gssd/svcgssd.man b/utils/gssd/svcgssd.man
index 7b2de6b..3688af0 100644
--- a/utils/gssd/svcgssd.man
+++ b/utils/gssd/svcgssd.man
@@ -45,6 +45,14 @@ Use the system default credentials
.RI (host/ FQDN @ REALM )
rather than the default
.RI nfs/ FQDN @ REALM .
+.TP
+.B -t timeout
+Timeout, in seconds, for kernel gss contexts. This option allows you to force
+new kernel contexts to be negotiated after
+.I timeout
+seconds, which allows changing Kerberos tickets and identities frequently.
+The default is no explicit timeout, which means the kernel context will live
+the lifetime of the Kerberos service ticket used in its creation.
.SH SEE ALSO
.BR rpc.gssd(8),
.SH AUTHORS
diff --git a/utils/gssd/svcgssd_proc.c b/utils/gssd/svcgssd_proc.c
index c714d99..dae10ca 100644
--- a/utils/gssd/svcgssd_proc.c
+++ b/utils/gssd/svcgssd_proc.c
@@ -497,6 +497,10 @@ handle_nullreq(FILE *f) {
/* We no longer need the gss context */
gss_delete_sec_context(&ignore_min_stat, &ctx, &ignore_out_tok);
+ /* If timeout set, override context timeout */
+ if (context_timeout)
+ ctx_endtime = time(0) + context_timeout;
+
do_svc_downcall(&out_handle, &cred, mech, &ctx_token, ctx_endtime,
hostbased_name);
continue_needed:
J. Bruce Fields wrote:
On Tue, Jan 17, 2012 at 11:31:33AM -0500, Jim Rees wrote:
> Sachin Prabhu wrote:
>
> On Tue, 2012-01-17 at 08:49 -0500, Jim Rees wrote:
> > Sachin Prabhu wrote:
> >
> > We had a user report that for an export shared with sec=krb5*, any
> > changes in user credentials(ex: add user to a secondary group) take some
> > time before they take effect over the NFS share.
> >
> > Re-authenticating, either by removing the service ticket or by re-running
> > kinit at the client, should also flush the old credentials. Can you confirm
> > that works?
>
> We have tried it but it doesn't work unless you actually clean up the
> cache on the NFS server with the command
> echo `date +'%s'` > /proc/net/rpc/auth.rpcsec.context/flush
>
> Bruce, shouldn't this work? Is this a bug or a feature?
kdestroy, kinit, etc. on the client only affect userspace; the NFS
client in the kernel continues to use the same gss context.
I would find it surprising if kdestroy didn't actually discard my
credentials. In fact I might even view this as a security risk.
On Tue, 2012-01-17 at 13:49 -0500, J. Bruce Fields wrote:
> On Tue, Jan 17, 2012 at 12:24:44PM -0500, Jim Rees wrote:
> > J. Bruce Fields wrote:
> >
> > On Tue, Jan 17, 2012 at 11:31:33AM -0500, Jim Rees wrote:
> > > Sachin Prabhu wrote:
> > >
> > > On Tue, 2012-01-17 at 08:49 -0500, Jim Rees wrote:
> > > > Sachin Prabhu wrote:
> > > >
> > > > We had a user report that for an export shared with sec=krb5*, any
> > > > changes in user credentials(ex: add user to a secondary group) take some
> > > > time before they take effect over the NFS share.
> > > >
> > > > Re-authenticating, either by removing the service ticket or by re-running
> > > > kinit at the client, should also flush the old credentials. Can you confirm
> > > > that works?
> > >
> > > We have tried it but it doesn't work unless you actually clean up the
> > > cache on the NFS server with the command
> > > echo `date +'%s'` > /proc/net/rpc/auth.rpcsec.context/flush
> > >
> > > Bruce, shouldn't this work? Is this a bug or a feature?
> >
> > kdestroy, kinit, etc. on the client only affect userspace; the NFS
> > client in the kernel continues to use the same gss context.
> >
> > I would find it surprising if kdestroy didn't actually discard my
> > credentials. In fact I might even view this as a security risk.
>
> Volunteers to fix this are welcomed.... I think this might be part of
> the project Simo Sorce is working on, but I'm not sure.
I have tested by setting a timeout on the the client side rpc.gssd.
Using kdestroy-kinit, I was able to get a new kerberos ticket and
subsequently force the NFS server to obtain new credentials for the
user.
I do agree with Jim Rees that this is a security issue. The user can use
kdestroy to destroy credentials before logging out. However the
credentials cached in the kernel will allow the user to continue
accessing the NFS share for as long as the cache is valid.
Sachin Prabhu
Sachin Prabhu wrote:
On Tue, 2012-01-17 at 08:49 -0500, Jim Rees wrote:
> Sachin Prabhu wrote:
>
> We had a user report that for an export shared with sec=krb5*, any
> changes in user credentials(ex: add user to a secondary group) take some
> time before they take effect over the NFS share.
>
> Re-authenticating, either by removing the service ticket or by re-running
> kinit at the client, should also flush the old credentials. Can you confirm
> that works?
We have tried it but it doesn't work unless you actually clean up the
cache on the NFS server with the command
echo `date +'%s'` > /proc/net/rpc/auth.rpcsec.context/flush
Bruce, shouldn't this work? Is this a bug or a feature?
Sachin Prabhu wrote:
We had a user report that for an export shared with sec=krb5*, any
changes in user credentials(ex: add user to a secondary group) take some
time before they take effect over the NFS share.
Re-authenticating, either by removing the service ticket or by re-running
kinit at the client, should also flush the old credentials. Can you confirm
that works?
On Tue, Jan 17, 2012 at 11:31:33AM -0500, Jim Rees wrote:
> Sachin Prabhu wrote:
>
> On Tue, 2012-01-17 at 08:49 -0500, Jim Rees wrote:
> > Sachin Prabhu wrote:
> >
> > We had a user report that for an export shared with sec=krb5*, any
> > changes in user credentials(ex: add user to a secondary group) take some
> > time before they take effect over the NFS share.
> >
> > Re-authenticating, either by removing the service ticket or by re-running
> > kinit at the client, should also flush the old credentials. Can you confirm
> > that works?
>
> We have tried it but it doesn't work unless you actually clean up the
> cache on the NFS server with the command
> echo `date +'%s'` > /proc/net/rpc/auth.rpcsec.context/flush
>
> Bruce, shouldn't this work? Is this a bug or a feature?
kdestroy, kinit, etc. on the client only affect userspace; the NFS
client in the kernel continues to use the same gss context.
You're right, if those commands did remove the gss context, then the
client would have to go get a new one, and that would trigger an svcgssd
on the server side that should get the up-to-date information.
--b.
On Tue, Jan 17, 2012 at 03:38:47PM +0000, Sachin Prabhu wrote:
> On Tue, 2012-01-17 at 08:49 -0500, Jim Rees wrote:
> > Sachin Prabhu wrote:
> >
> > We had a user report that for an export shared with sec=krb5*, any
> > changes in user credentials(ex: add user to a secondary group) take some
> > time before they take effect over the NFS share.
> >
> > Re-authenticating, either by removing the service ticket or by re-running
> > kinit at the client, should also flush the old credentials. Can you confirm
> > that works?
>
> We have tried it but it doesn't work unless you actually clean up the
> cache on the NFS server with the command
> echo `date +'%s'` > /proc/net/rpc/auth.rpcsec.context/flush
>
> To reproduce:
> 1) Export a nfs4 share using kerberos authentication
> /export-krb5 *(rw,sec=krb5)
> 2) Create user foo part of group foo. Make sure that the user details
> for this user are available both on client and server.
> 3) Create group bar.
> 4) Create 2 directories on the nfs share.
> Directory foo with ownership root.foo and mode set to 2775
> Directory bar with ownership root.bar and mode set to 2775
>
> On the client,
> 1) mount the share export from the nfs server from step1
> 2) Login and obtain a kerberos principal for user foo.
> 3) create file in /mnt/foo/ and confirm that the user can write to the
> directory
> 4) try and create file in /mnt/bar. This should fail since the user
> doesn't have permissions to write to this directory.
> 5) Modify user foo to add additional group bar. Make sure that these
> details are available on both the nfs server and client.
> 6) Re-login as foo and confirm that the user is part of group bar using
> the id command. Re-initialise the kerberos ticket.
> 7) try creating file in /mnt/foo. This is successful.
> 8) try creating file in /mnt/bar. This fails even though user has
> permission to write to this directory.
I think that's because none of these client operations actually destroy
the context kept in the kernel on the client side. You probably will
see the change if you add an umount/mount step between client steps 5
and 6.
That should be fixed too, some day.
It might also be nice to have a server-side command that does the
/proc/net/rpc/auth.rpcsec.context/flush thing. I'm not sure what a good
UI would be.
But the configurable timeout also seems like a reasonable thing to have.
--b.
On Tue, 2012-01-17 at 08:49 -0500, Jim Rees wrote:
> Sachin Prabhu wrote:
>
> We had a user report that for an export shared with sec=krb5*, any
> changes in user credentials(ex: add user to a secondary group) take some
> time before they take effect over the NFS share.
>
> Re-authenticating, either by removing the service ticket or by re-running
> kinit at the client, should also flush the old credentials. Can you confirm
> that works?
We have tried it but it doesn't work unless you actually clean up the
cache on the NFS server with the command
echo `date +'%s'` > /proc/net/rpc/auth.rpcsec.context/flush
To reproduce:
1) Export a nfs4 share using kerberos authentication
/export-krb5 *(rw,sec=krb5)
2) Create user foo part of group foo. Make sure that the user details
for this user are available both on client and server.
3) Create group bar.
4) Create 2 directories on the nfs share.
Directory foo with ownership root.foo and mode set to 2775
Directory bar with ownership root.bar and mode set to 2775
On the client,
1) mount the share export from the nfs server from step1
2) Login and obtain a kerberos principal for user foo.
3) create file in /mnt/foo/ and confirm that the user can write to the
directory
4) try and create file in /mnt/bar. This should fail since the user
doesn't have permissions to write to this directory.
5) Modify user foo to add additional group bar. Make sure that these
details are available on both the nfs server and client.
6) Re-login as foo and confirm that the user is part of group bar using
the id command. Re-initialise the kerberos ticket.
7) try creating file in /mnt/foo. This is successful.
8) try creating file in /mnt/bar. This fails even though user has
permission to write to this directory.
Sachin Prabhu
On Tue, Jan 17, 2012 at 12:24:44PM -0500, Jim Rees wrote:
> J. Bruce Fields wrote:
>
> On Tue, Jan 17, 2012 at 11:31:33AM -0500, Jim Rees wrote:
> > Sachin Prabhu wrote:
> >
> > On Tue, 2012-01-17 at 08:49 -0500, Jim Rees wrote:
> > > Sachin Prabhu wrote:
> > >
> > > We had a user report that for an export shared with sec=krb5*, any
> > > changes in user credentials(ex: add user to a secondary group) take some
> > > time before they take effect over the NFS share.
> > >
> > > Re-authenticating, either by removing the service ticket or by re-running
> > > kinit at the client, should also flush the old credentials. Can you confirm
> > > that works?
> >
> > We have tried it but it doesn't work unless you actually clean up the
> > cache on the NFS server with the command
> > echo `date +'%s'` > /proc/net/rpc/auth.rpcsec.context/flush
> >
> > Bruce, shouldn't this work? Is this a bug or a feature?
>
> kdestroy, kinit, etc. on the client only affect userspace; the NFS
> client in the kernel continues to use the same gss context.
>
> I would find it surprising if kdestroy didn't actually discard my
> credentials. In fact I might even view this as a security risk.
Volunteers to fix this are welcomed.... I think this might be part of
the project Simo Sorce is working on, but I'm not sure.
--b.