RPCGSSD and root on Linux client

RPCGSSD and root on Linux client

[Muntz, Daniel]

We've hit the following issue with root and Kerberos on the linux
client:

> I run in into interesting problem with recent change to rpcgssd on the

> linux client.
> The change itself made -m flag mandatory, meaning that for user uid = 
> 0 , different principal will be used, namely first principal specified

> in /etc/krb5.keytab which starts with nfs. From the filer perspective 
> after that change there is no way root will come in as a principal 
> over RPCSEC_GSS so, for example, root can't create a file with root as

> owner. I'm not sure how Linux nfs server handles this, but behavior 
> seems broken. Do you know what was the rationale behind this change?
> am I missing something?

Our guess at what's going on here is that gssd was changed so that
initial mounts and the automounter could acquire a cred even when there
is no root cred available on the machine.  Unfortunately, the change to
gssd maps all uid=0 requests to a non-root principal.  Currently the
code does something like this:

  if (uid == 0)
	map some non-root principal to uid 0
  else
      do normal uid->principal mapping

I'm suggesting chaging this logic to:

  do normal uid->principal mapping
  if mapping failed && uid == 0
	map some non-root principal to uid 0 (as in the original case)

So, if we have a root cred hanging around (e.g., in krb5.keytab, via
kinit, etc.), we go ahead and use it.  Otherwise, we use the existing
code to map uid 0 to some other principal.  In either case, automount,
mounts during startup, etc. should be happy, but we're still able to use
the root principal.

Patch below is **untested** but illustrates the proposed change.

We need to know if we've missed something in the reasoning for the
original change that impacts the proposed solution.  Or if the proposal
is flawed in some other respect :-)

  -Dan

 
--- gssd_proc.c.orig	2007-03-08 15:22:40.637927000 -0800
+++ gssd_proc.c	2007-03-08 15:28:00.671967000 -0800
@@ -688,6 +688,18 @@ handle_krb5_upcall(struct clnt_info *clp
 		goto out;
 	}
 
+	/* Tell krb5 gss which credentials cache to use */
+	gssd_setup_krb5_user_gss_ccache(uid, clp->servername);
+
+	if (create_auth_rpc_client(clp, &rpc_clnt, &auth, uid,
+				AUTHTYPE_KRB5) != 0 && 
+			uid != 0) {
+		printerr(0, "WARNING: Failed to create krb5 context "
+		    "for user with uid %d for server %s\n",
+			 uid, clp->servername);
+		goto out_return_error;
+	}
+
 	if (uid == 0) {
 		int success = 0;
 
@@ -723,18 +735,6 @@ handle_krb5_upcall(struct clnt_info *clp
 			goto out_return_error;
 		}
 	}
-	else {
-		/* Tell krb5 gss which credentials cache to use */
-		gssd_setup_krb5_user_gss_ccache(uid, clp->servername);
-
-		if ((create_auth_rpc_client(clp, &rpc_clnt, &auth, uid,
-							AUTHTYPE_KRB5))
!= 0) {
-			printerr(0, "WARNING: Failed to create krb5
context "
-				    "for user with uid %d for server
%s\n",
-				 uid, clp->servername);
-			goto out_return_error;
-		}
-	}
 
 	if (!authgss_get_private_data(auth, &pd)) {
 		printerr(0, "WARNING: Failed to obtain authentication "

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: RPCGSSD and root on Linux client

[Muntz, Daniel]

Original message and pseudo code logic are correct, but the patch is
broken.  Here's the new, slightly cleaner one (still for illustrative
purposes only :)

--- gssd_proc.c.orig	2007-03-08 15:22:40.637927000 -0800
+++ gssd_proc.c	2007-03-08 16:50:08.104133000 -0800
@@ -675,6 +675,7 @@ handle_krb5_upcall(struct clnt_info *clp
 	gss_buffer_desc		token;
 	char			**credlist = NULL;
 	char			**ccname;
+	int			create_resp;
 
 	printerr(1, "handling krb5 upcall\n");
 
@@ -688,7 +689,19 @@ handle_krb5_upcall(struct clnt_info *clp
 		goto out;
 	}
 
-	if (uid == 0) {
+	/* Tell krb5 gss which credentials cache to use */
+	gssd_setup_krb5_user_gss_ccache(uid, clp->servername);
+
+	create_resp = create_auth_rpc_client(clp, &rpc_clnt, &auth, uid,
+				AUTHTYPE_KRB5);
+	if (create_resp != 0 && uid != 0) {
+		printerr(0, "WARNING: Failed to create krb5 context "
+		    "for user with uid %d for server %s\n",
+			 uid, clp->servername);
+		goto out_return_error;
+	}
+
+	if (create_resp != 0 && uid == 0) {
 		int success = 0;
 
 		/*
@@ -723,18 +736,6 @@ handle_krb5_upcall(struct clnt_info *clp
 			goto out_return_error;
 		}
 	}
-	else {
-		/* Tell krb5 gss which credentials cache to use */
-		gssd_setup_krb5_user_gss_ccache(uid, clp->servername);
-
-		if ((create_auth_rpc_client(clp, &rpc_clnt, &auth, uid,
-							AUTHTYPE_KRB5))
!= 0) {
-			printerr(0, "WARNING: Failed to create krb5
context "
-				    "for user with uid %d for server
%s\n",
-				 uid, clp->servername);
-			goto out_return_error;
-		}
-	}
 
 	if (!authgss_get_private_data(auth, &pd)) {
 		printerr(0, "WARNING: Failed to obtain authentication "

 

-----Original Message-----
From: Muntz, Daniel 
Sent: Thursday, March 08, 2007 3:59 PM
To: nfs@lists.sourceforge.net
Cc: Burlyga, Alex
Subject: [NFS] RPCGSSD and root on Linux client

We've hit the following issue with root and Kerberos on the linux
client:

> I run in into interesting problem with recent change to rpcgssd on the

> linux client.
> The change itself made -m flag mandatory, meaning that for user uid = 
> 0 , different principal will be used, namely first principal specified

> in /etc/krb5.keytab which starts with nfs. From the filer perspective 
> after that change there is no way root will come in as a principal 
> over RPCSEC_GSS so, for example, root can't create a file with root as

> owner. I'm not sure how Linux nfs server handles this, but behavior 
> seems broken. Do you know what was the rationale behind this change?
> am I missing something?

Our guess at what's going on here is that gssd was changed so that
initial mounts and the automounter could acquire a cred even when there
is no root cred available on the machine.  Unfortunately, the change to
gssd maps all uid=0 requests to a non-root principal.  Currently the
code does something like this:

  if (uid == 0)
	map some non-root principal to uid 0
  else
      do normal uid->principal mapping

I'm suggesting chaging this logic to:

  do normal uid->principal mapping
  if mapping failed && uid == 0
	map some non-root principal to uid 0 (as in the original case)

So, if we have a root cred hanging around (e.g., in krb5.keytab, via
kinit, etc.), we go ahead and use it.  Otherwise, we use the existing
code to map uid 0 to some other principal.  In either case, automount,
mounts during startup, etc. should be happy, but we're still able to use
the root principal.

Patch below is **untested** but illustrates the proposed change.

We need to know if we've missed something in the reasoning for the
original change that impacts the proposed solution.  Or if the proposal
is flawed in some other respect :-)

  -Dan

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: RPCGSSD and root on Linux client

[Kevin Coffman]

Hi Dan,
Thanks.  I think this sounds reasonable at first glance.  I'll try it out.

There has also been interest in allowing the use of any usable key
found in the keytab when using the machine credentials.  This would
allow the use of a "host/<machine.name>@REALM" or
"root/<machine.name>@REALM" key rather than requiring an
"nfs/<machine.name>@REALM" key on the client.   I'll look into this as
well.  (I have to look back at the spec to see if the callback channel
authentication requires an nfs key on the client.  I don't think it
does.)

K.C.

On 3/8/07, Muntz, Daniel <Dan.Muntz@netapp.com> wrote:
> Original message and pseudo code logic are correct, but the patch is
> broken.  Here's the new, slightly cleaner one (still for illustrative
> purposes only :)
>
> --- gssd_proc.c.orig    2007-03-08 15:22:40.637927000 -0800
> +++ gssd_proc.c 2007-03-08 16:50:08.104133000 -0800
> @@ -675,6 +675,7 @@ handle_krb5_upcall(struct clnt_info *clp
>         gss_buffer_desc         token;
>         char                    **credlist = NULL;
>         char                    **ccname;
> +       int                     create_resp;
>
>         printerr(1, "handling krb5 upcall\n");
>
> @@ -688,7 +689,19 @@ handle_krb5_upcall(struct clnt_info *clp
>                 goto out;
>         }
>
> -       if (uid == 0) {
> +       /* Tell krb5 gss which credentials cache to use */
> +       gssd_setup_krb5_user_gss_ccache(uid, clp->servername);
> +
> +       create_resp = create_auth_rpc_client(clp, &rpc_clnt, &auth, uid,
> +                               AUTHTYPE_KRB5);
> +       if (create_resp != 0 && uid != 0) {
> +               printerr(0, "WARNING: Failed to create krb5 context "
> +                   "for user with uid %d for server %s\n",
> +                        uid, clp->servername);
> +               goto out_return_error;
> +       }
> +
> +       if (create_resp != 0 && uid == 0) {
>                 int success = 0;
>
>                 /*
> @@ -723,18 +736,6 @@ handle_krb5_upcall(struct clnt_info *clp
>                         goto out_return_error;
>                 }
>         }
> -       else {
> -               /* Tell krb5 gss which credentials cache to use */
> -               gssd_setup_krb5_user_gss_ccache(uid, clp->servername);
> -
> -               if ((create_auth_rpc_client(clp, &rpc_clnt, &auth, uid,
> -                                                       AUTHTYPE_KRB5))
> != 0) {
> -                       printerr(0, "WARNING: Failed to create krb5
> context "
> -                                   "for user with uid %d for server
> %s\n",
> -                                uid, clp->servername);
> -                       goto out_return_error;
> -               }
> -       }
>
>         if (!authgss_get_private_data(auth, &pd)) {
>                 printerr(0, "WARNING: Failed to obtain authentication "
>
>
>
> -----Original Message-----
> From: Muntz, Daniel
> Sent: Thursday, March 08, 2007 3:59 PM
> To: nfs@lists.sourceforge.net
> Cc: Burlyga, Alex
> Subject: [NFS] RPCGSSD and root on Linux client
>
> We've hit the following issue with root and Kerberos on the linux
> client:
>
> > I run in into interesting problem with recent change to rpcgssd on the
>
> > linux client.
> > The change itself made -m flag mandatory, meaning that for user uid =
> > 0 , different principal will be used, namely first principal specified
>
> > in /etc/krb5.keytab which starts with nfs. From the filer perspective
> > after that change there is no way root will come in as a principal
> > over RPCSEC_GSS so, for example, root can't create a file with root as
>
> > owner. I'm not sure how Linux nfs server handles this, but behavior
> > seems broken. Do you know what was the rationale behind this change?
> > am I missing something?
>
> Our guess at what's going on here is that gssd was changed so that
> initial mounts and the automounter could acquire a cred even when there
> is no root cred available on the machine.  Unfortunately, the change to
> gssd maps all uid=0 requests to a non-root principal.  Currently the
> code does something like this:
>
>   if (uid == 0)
>         map some non-root principal to uid 0
>   else
>       do normal uid->principal mapping
>
> I'm suggesting chaging this logic to:
>
>   do normal uid->principal mapping
>   if mapping failed && uid == 0
>         map some non-root principal to uid 0 (as in the original case)
>
> So, if we have a root cred hanging around (e.g., in krb5.keytab, via
> kinit, etc.), we go ahead and use it.  Otherwise, we use the existing
> code to map uid 0 to some other principal.  In either case, automount,
> mounts during startup, etc. should be happy, but we're still able to use
> the root principal.
>
> Patch below is **untested** but illustrates the proposed change.
>
> We need to know if we've missed something in the reasoning for the
> original change that impacts the proposed solution.  Or if the proposal
> is flawed in some other respect :-)
>
>   -Dan
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> NFS maillist  -  NFS@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs
>
>

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: RPCGSSD and root on Linux client

[Kevin Coffman]

After thinking about this a bit more, I have a concern.

Let's say root authenticates as "foo@REALM" and begins accessing NFS
files using those credentials.  Some time later, the context expires
or must be recreated for some reason and root's credentials cache is
now either expired or has been destroyed.  The initial context
creation will fail and we will fall back and use the machine
credentials to create the new context.  This will cause confusion
because all of the sudden root is "nfs/<machine>@REALM" rather than
"foo@REALM".

Any suggestions on a way around this?

K.C.

On 3/9/07, Kevin Coffman <kwc@citi.umich.edu> wrote:
> Hi Dan,
> Thanks.  I think this sounds reasonable at first glance.  I'll try it out.
>
> There has also been interest in allowing the use of any usable key
> found in the keytab when using the machine credentials.  This would
> allow the use of a "host/<machine.name>@REALM" or
> "root/<machine.name>@REALM" key rather than requiring an
> "nfs/<machine.name>@REALM" key on the client.   I'll look into this as
> well.  (I have to look back at the spec to see if the callback channel
> authentication requires an nfs key on the client.  I don't think it
> does.)
>
> K.C.
>
> On 3/8/07, Muntz, Daniel <Dan.Muntz@netapp.com> wrote:
> > Original message and pseudo code logic are correct, but the patch is
> > broken.  Here's the new, slightly cleaner one (still for illustrative
> > purposes only :)
> >
> > --- gssd_proc.c.orig    2007-03-08 15:22:40.637927000 -0800
> > +++ gssd_proc.c 2007-03-08 16:50:08.104133000 -0800
> > @@ -675,6 +675,7 @@ handle_krb5_upcall(struct clnt_info *clp
> >         gss_buffer_desc         token;
> >         char                    **credlist = NULL;
> >         char                    **ccname;
> > +       int                     create_resp;
> >
> >         printerr(1, "handling krb5 upcall\n");
> >
> > @@ -688,7 +689,19 @@ handle_krb5_upcall(struct clnt_info *clp
> >                 goto out;
> >         }
> >
> > -       if (uid == 0) {
> > +       /* Tell krb5 gss which credentials cache to use */
> > +       gssd_setup_krb5_user_gss_ccache(uid, clp->servername);
> > +
> > +       create_resp = create_auth_rpc_client(clp, &rpc_clnt, &auth, uid,
> > +                               AUTHTYPE_KRB5);
> > +       if (create_resp != 0 && uid != 0) {
> > +               printerr(0, "WARNING: Failed to create krb5 context "
> > +                   "for user with uid %d for server %s\n",
> > +                        uid, clp->servername);
> > +               goto out_return_error;
> > +       }
> > +
> > +       if (create_resp != 0 && uid == 0) {
> >                 int success = 0;
> >
> >                 /*
> > @@ -723,18 +736,6 @@ handle_krb5_upcall(struct clnt_info *clp
> >                         goto out_return_error;
> >                 }
> >         }
> > -       else {
> > -               /* Tell krb5 gss which credentials cache to use */
> > -               gssd_setup_krb5_user_gss_ccache(uid, clp->servername);
> > -
> > -               if ((create_auth_rpc_client(clp, &rpc_clnt, &auth, uid,
> > -                                                       AUTHTYPE_KRB5))
> > != 0) {
> > -                       printerr(0, "WARNING: Failed to create krb5
> > context "
> > -                                   "for user with uid %d for server
> > %s\n",
> > -                                uid, clp->servername);
> > -                       goto out_return_error;
> > -               }
> > -       }
> >
> >         if (!authgss_get_private_data(auth, &pd)) {
> >                 printerr(0, "WARNING: Failed to obtain authentication "
> >
> >
> >
> > -----Original Message-----
> > From: Muntz, Daniel
> > Sent: Thursday, March 08, 2007 3:59 PM
> > To: nfs@lists.sourceforge.net
> > Cc: Burlyga, Alex
> > Subject: [NFS] RPCGSSD and root on Linux client
> >
> > We've hit the following issue with root and Kerberos on the linux
> > client:
> >
> > > I run in into interesting problem with recent change to rpcgssd on the
> >
> > > linux client.
> > > The change itself made -m flag mandatory, meaning that for user uid =
> > > 0 , different principal will be used, namely first principal specified
> >
> > > in /etc/krb5.keytab which starts with nfs. From the filer perspective
> > > after that change there is no way root will come in as a principal
> > > over RPCSEC_GSS so, for example, root can't create a file with root as
> >
> > > owner. I'm not sure how Linux nfs server handles this, but behavior
> > > seems broken. Do you know what was the rationale behind this change?
> > > am I missing something?
> >
> > Our guess at what's going on here is that gssd was changed so that
> > initial mounts and the automounter could acquire a cred even when there
> > is no root cred available on the machine.  Unfortunately, the change to
> > gssd maps all uid=0 requests to a non-root principal.  Currently the
> > code does something like this:
> >
> >   if (uid == 0)
> >         map some non-root principal to uid 0
> >   else
> >       do normal uid->principal mapping
> >
> > I'm suggesting chaging this logic to:
> >
> >   do normal uid->principal mapping
> >   if mapping failed && uid == 0
> >         map some non-root principal to uid 0 (as in the original case)
> >
> > So, if we have a root cred hanging around (e.g., in krb5.keytab, via
> > kinit, etc.), we go ahead and use it.  Otherwise, we use the existing
> > code to map uid 0 to some other principal.  In either case, automount,
> > mounts during startup, etc. should be happy, but we're still able to use
> > the root principal.
> >
> > Patch below is **untested** but illustrates the proposed change.
> >
> > We need to know if we've missed something in the reasoning for the
> > original change that impacts the proposed solution.  Or if the proposal
> > is flawed in some other respect :-)
> >
> >   -Dan
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share your
> > opinions on IT & business topics through brief surveys-and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > NFS maillist  -  NFS@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/nfs
> >
> >
>

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: RPCGSSD and root on Linux client

[Muntz, Daniel]

With the current code, root can't authenticate as foo@REALM (or
root@REALM, or root/<machine>@REALM, ...).  gssd will always map root to
the machine cred.  With the patch, you would at least be able to
authenticate as foo@REALM, with the caveat that the cred will revert to
the machine cred if you fail to renew.

I guess we have a question for the maintainer/community: which behavior
is less broken? :)

Our concern is that there be some way for root to authenticate as
root[/<machine>]@REALM so "root can be root" w.r.t. the server.

We were also thinking about the root/<machine>@REALM angle--moving
towards the Solaris model.

  -Dan 

-----Original Message-----
From: Kevin Coffman [mailto:kwc@citi.umich.edu] 
Sent: Friday, March 09, 2007 8:14 AM
To: Muntz, Daniel
Cc: Burlyga, Alex; nfs@lists.sourceforge.net
Subject: Re: [NFS] RPCGSSD and root on Linux client

After thinking about this a bit more, I have a concern.

Let's say root authenticates as "foo@REALM" and begins accessing NFS
files using those credentials.  Some time later, the context expires or
must be recreated for some reason and root's credentials cache is now
either expired or has been destroyed.  The initial context creation will
fail and we will fall back and use the machine credentials to create the
new context.  This will cause confusion because all of the sudden root
is "nfs/<machine>@REALM" rather than "foo@REALM".

Any suggestions on a way around this?

K.C.

On 3/9/07, Kevin Coffman <kwc@citi.umich.edu> wrote:
> Hi Dan,
> Thanks.  I think this sounds reasonable at first glance.  I'll try it
out.
>
> There has also been interest in allowing the use of any usable key 
> found in the keytab when using the machine credentials.  This would 
> allow the use of a "host/<machine.name>@REALM" or 
> "root/<machine.name>@REALM" key rather than requiring an
> "nfs/<machine.name>@REALM" key on the client.   I'll look into this as
> well.  (I have to look back at the spec to see if the callback channel

> authentication requires an nfs key on the client.  I don't think it
> does.)
>
> K.C.
>
> On 3/8/07, Muntz, Daniel <Dan.Muntz@netapp.com> wrote:
> > Original message and pseudo code logic are correct, but the patch is

> > broken.  Here's the new, slightly cleaner one (still for 
> > illustrative purposes only :)
> >
> > --- gssd_proc.c.orig    2007-03-08 15:22:40.637927000 -0800
> > +++ gssd_proc.c 2007-03-08 16:50:08.104133000 -0800
> > @@ -675,6 +675,7 @@ handle_krb5_upcall(struct clnt_info *clp
> >         gss_buffer_desc         token;
> >         char                    **credlist = NULL;
> >         char                    **ccname;
> > +       int                     create_resp;
> >
> >         printerr(1, "handling krb5 upcall\n");
> >
> > @@ -688,7 +689,19 @@ handle_krb5_upcall(struct clnt_info *clp
> >                 goto out;
> >         }
> >
> > -       if (uid == 0) {
> > +       /* Tell krb5 gss which credentials cache to use */
> > +       gssd_setup_krb5_user_gss_ccache(uid, clp->servername);
> > +
> > +       create_resp = create_auth_rpc_client(clp, &rpc_clnt, &auth,
uid,
> > +                               AUTHTYPE_KRB5);
> > +       if (create_resp != 0 && uid != 0) {
> > +               printerr(0, "WARNING: Failed to create krb5 context
"
> > +                   "for user with uid %d for server %s\n",
> > +                        uid, clp->servername);
> > +               goto out_return_error;
> > +       }
> > +
> > +       if (create_resp != 0 && uid == 0) {
> >                 int success = 0;
> >
> >                 /*
> > @@ -723,18 +736,6 @@ handle_krb5_upcall(struct clnt_info *clp
> >                         goto out_return_error;
> >                 }
> >         }
> > -       else {
> > -               /* Tell krb5 gss which credentials cache to use */
> > -               gssd_setup_krb5_user_gss_ccache(uid,
clp->servername);
> > -
> > -               if ((create_auth_rpc_client(clp, &rpc_clnt, &auth,
uid,
> > -
AUTHTYPE_KRB5))
> > != 0) {
> > -                       printerr(0, "WARNING: Failed to create krb5
> > context "
> > -                                   "for user with uid %d for server
> > %s\n",
> > -                                uid, clp->servername);
> > -                       goto out_return_error;
> > -               }
> > -       }
> >
> >         if (!authgss_get_private_data(auth, &pd)) {
> >                 printerr(0, "WARNING: Failed to obtain
authentication "
> >
> >
> >
> > -----Original Message-----
> > From: Muntz, Daniel
> > Sent: Thursday, March 08, 2007 3:59 PM
> > To: nfs@lists.sourceforge.net
> > Cc: Burlyga, Alex
> > Subject: [NFS] RPCGSSD and root on Linux client
> >
> > We've hit the following issue with root and Kerberos on the linux
> > client:
> >
> > > I run in into interesting problem with recent change to rpcgssd on

> > > the
> >
> > > linux client.
> > > The change itself made -m flag mandatory, meaning that for user 
> > > uid = 0 , different principal will be used, namely first principal

> > > specified
> >
> > > in /etc/krb5.keytab which starts with nfs. From the filer 
> > > perspective after that change there is no way root will come in as

> > > a principal over RPCSEC_GSS so, for example, root can't create a 
> > > file with root as
> >
> > > owner. I'm not sure how Linux nfs server handles this, but 
> > > behavior seems broken. Do you know what was the rationale behind
this change?
> > > am I missing something?
> >
> > Our guess at what's going on here is that gssd was changed so that 
> > initial mounts and the automounter could acquire a cred even when 
> > there is no root cred available on the machine.  Unfortunately, the 
> > change to gssd maps all uid=0 requests to a non-root principal.  
> > Currently the code does something like this:
> >
> >   if (uid == 0)
> >         map some non-root principal to uid 0
> >   else
> >       do normal uid->principal mapping
> >
> > I'm suggesting chaging this logic to:
> >
> >   do normal uid->principal mapping
> >   if mapping failed && uid == 0
> >         map some non-root principal to uid 0 (as in the original 
> > case)
> >
> > So, if we have a root cred hanging around (e.g., in krb5.keytab, via

> > kinit, etc.), we go ahead and use it.  Otherwise, we use the 
> > existing code to map uid 0 to some other principal.  In either case,

> > automount, mounts during startup, etc. should be happy, but we're 
> > still able to use the root principal.
> >
> > Patch below is **untested** but illustrates the proposed change.
> >
> > We need to know if we've missed something in the reasoning for the 
> > original change that impacts the proposed solution.  Or if the 
> > proposal is flawed in some other respect :-)
> >
> >   -Dan
> >
> > --------------------------------------------------------------------
> > ----- Take Surveys. Earn Cash. Influence the Future of IT Join 
> > SourceForge.net's Techsay panel and you'll get the chance to share 
> > your opinions on IT & business topics through brief surveys-and earn

> > cash 
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=D
> > EVDEV _______________________________________________
> > NFS maillist  -  NFS@lists.sourceforge.net 
> > https://lists.sourceforge.net/lists/listinfo/nfs
> >
> >
>

------------------------------------------------------------------------
-
Take Surveys. Earn Cash. Influence the Future of IT Join
SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
V
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: RPCGSSD and root on Linux client

[J. Bruce Fields]

On Fri, Mar 09, 2007 at 11:14:05AM -0500, Kevin Coffman wrote:
> After thinking about this a bit more, I have a concern.
> 
> Let's say root authenticates as "foo@REALM" and begins accessing NFS
> files using those credentials.  Some time later, the context expires
> or must be recreated for some reason and root's credentials cache is
> now either expired or has been destroyed.  The initial context
> creation will fail and we will fall back and use the machine
> credentials to create the new context.  This will cause confusion
> because all of the sudden root is "nfs/<machine>@REALM" rather than
> "foo@REALM".
> 
> Any suggestions on a way around this?

We might want to make sure this behavior is optional somehow--it could
be the reason they have an nfs/host@REALM cred is because the host is
also an NFS server, not because they want the client using it for root.

Given that, if  a user/administrator sets things up to allow gssd to
fall back on a different credential, then, well, that's what they asked
for....

--b.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: RPCGSSD and root on Linux client

[Muntz, Daniel]

Gssd just wants any valid cred.  I'm guessing the '-m' author chose
nfs[/host]@REALM because they were pretty sure that if you were doing an
NFS mount that you'd have the nfs service cred :-)  But the current code
that makes the (once optional) '-m' behavior always on, thus always
hijacking root, is a problem (imo).

  -Dan

-----Original Message-----
From: J. Bruce Fields [mailto:bfields@fieldses.org] 
Sent: Saturday, March 10, 2007 9:04 AM
To: Kevin Coffman
Cc: Muntz, Daniel; Burlyga, Alex; nfs@lists.sourceforge.net
Subject: Re: [NFS] RPCGSSD and root on Linux client

On Fri, Mar 09, 2007 at 11:14:05AM -0500, Kevin Coffman wrote:
> After thinking about this a bit more, I have a concern.
> 
> Let's say root authenticates as "foo@REALM" and begins accessing NFS 
> files using those credentials.  Some time later, the context expires 
> or must be recreated for some reason and root's credentials cache is 
> now either expired or has been destroyed.  The initial context 
> creation will fail and we will fall back and use the machine 
> credentials to create the new context.  This will cause confusion 
> because all of the sudden root is "nfs/<machine>@REALM" rather than 
> "foo@REALM".
> 
> Any suggestions on a way around this?

We might want to make sure this behavior is optional somehow--it could
be the reason they have an nfs/host@REALM cred is because the host is
also an NFS server, not because they want the client using it for root.

Given that, if  a user/administrator sets things up to allow gssd to
fall back on a different credential, then, well, that's what they asked
for....

--b.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: RPCGSSD and root on Linux client

[Kevin Coffman]

On 3/10/07, Muntz, Daniel <Dan.Muntz@netapp.com> wrote:
> -----Original Message-----
> From: J. Bruce Fields [mailto:bfields@fieldses.org]
> Sent: Saturday, March 10, 2007 9:04 AM
> To: Kevin Coffman
> Cc: Muntz, Daniel; Burlyga, Alex; nfs@lists.sourceforge.net
> Subject: Re: [NFS] RPCGSSD and root on Linux client
>
> On Fri, Mar 09, 2007 at 11:14:05AM -0500, Kevin Coffman wrote:
> > After thinking about this a bit more, I have a concern.
> >
> > Let's say root authenticates as "foo@REALM" and begins accessing NFS
> > files using those credentials.  Some time later, the context expires
> > or must be recreated for some reason and root's credentials cache is
> > now either expired or has been destroyed.  The initial context
> > creation will fail and we will fall back and use the machine
> > credentials to create the new context.  This will cause confusion
> > because all of the sudden root is "nfs/<machine>@REALM" rather than
> > "foo@REALM".
> >
> > Any suggestions on a way around this?
>
> We might want to make sure this behavior is optional somehow--it could
> be the reason they have an nfs/host@REALM cred is because the host is
> also an NFS server, not because they want the client using it for root.
>
> Given that, if  a user/administrator sets things up to allow gssd to
> fall back on a different credential, then, well, that's what they asked
> for....
>
> --b.
> Gssd just wants any valid cred.  I'm guessing the '-m' author chose
> nfs[/host]@REALM because they were pretty sure that if you were doing an
> NFS mount that you'd have the nfs service cred :-)  But the current code
> that makes the (once optional) '-m' behavior always on, thus always
> hijacking root, is a problem (imo).
>
>   -Dan

I don't like the idea of things changing suddenly for no apparent
reason (root accesses falling back to using machine creds after other
credentials expire).  I think the default behavior should remain as it
is (using machine creds for root access).  [BTW, making "-m" the
default behavior wasn't a "recent change" and it (the -m option) was
never in an official nfs-utils release.]

I'm tempted to create a new option (-n ?) that says that root should
not use machine credentials.  Use of this option will require that
root authenticates somehow before attempting a mount requiring
Kerberos.

A seperate patch would allow the use of any keytab entry found in the
keytab to be used as the machine credentials.

It seems nfs-utils-1.1.0 might be a good time to introduce this change.

Does that sound reasonable?

K.C.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs