[PATCH 06/11] nfs-utils: mount: AUTH_NONE mounts

Steve Dickson

author

2007-02-26 11:15 UTC #0 lore raw

PATCH 6/11 nfs-utils: mount: AUTH_NONE mounts

commit 0ffd74c990aca3761b79316d47e1b1778273681c

Author: Steve Dickson <[email protected]>
Date:   Sat Feb 24 15:27:46 2007 -0500

Added support to specify the AUTH_NONE security flavor (i.e. -o sec=none)

Signed-off-by Steve Dickson <[email protected]>

utils/mount/nfsmount.c +6 -4

index d437036..7759260 100644
@@ -1093,12 +1093,14 @@ nfsmount(const char *spec, const char *node, int *flags,
 
 		flavor = mountres->auth_flavors.auth_flavors_val;
 		while (--i >= 0) {
-			if (flavor[i] == data.pseudoflavor)
-				yum = 1;
 #ifdef NFS_MOUNT_DEBUG
-			printf("auth flavor %d: %d\n",
-				i, flavor[i]);
+			printf("auth flavor[%d] %d\n", i, flavor[i]);
 #endif
+			if (flavor[i] == data.pseudoflavor ||
+				flavor[i] == AUTH_NONE) {
+				yum = 1;
+				break;
+			}
 		}
 		if (!yum) {
 			fprintf(stderr,

-------------------------------------------------------------------------
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Neil Brown

2007-02-27 06:15 UTC #1 lore raw

Quoted 5 lines · On Monday February 26, [email protected] wrote:

commit 0ffd74c990aca3761b79316d47e1b1778273681c
Author: Steve Dickson <[email protected]>
Date:   Sat Feb 24 15:27:46 2007 -0500
Added support to specify the AUTH_NONE security flavor (i.e. -o sec=none)

If you specify "-o sec=none" then data.pseudoflavor will == AUTH_NONE, but

Quoted 13 lines

Signed-off-by Steve Dickson <[email protected]>

utils/mount/nfsmount.c +0 -2

index d437036..7759260 100644
@@ -1093,12 +1093,14 @@ nfsmount(const char *spec, const char *node, int *flags,
 
 		flavor = mountres->auth_flavors.auth_flavors_val;
 		while (--i >= 0) {
-			if (flavor[i] == data.pseudoflavor)
-				yum = 1;

utils/mount/nfsmount.c nfsmount(const char *spec, const char *node, int *flags, · line 1103

Quoted 10 lines

utils/mount/nfsmount.c +6 -2

 #ifdef NFS_MOUNT_DEBUG
-			printf("auth flavor %d: %d\n",
-				i, flavor[i]);
+			printf("auth flavor[%d] %d\n", i, flavor[i]);
 #endif
+			if (flavor[i] == data.pseudoflavor ||
+				flavor[i] == AUTH_NONE) {
+				yum = 1;
+				break;
+			}

You are testing if flavor[i] == AUTH_NONE, which doesn't make sense to me....

NeilBrown

-------------------------------------------------------------------------
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Peter Staubach

2007-02-27 14:13 UTC #2 lore raw

Quoted 6 lines · Neil Brown

Quoted 4 lines · On Monday February 26, [email protected] wrote:
commit 0ffd74c990aca3761b79316d47e1b1778273681c
Author: Steve Dickson <[email protected]>
Date:   Sat Feb 24 15:27:46 2007 -0500

Quoted 7 lines

Quoted 2 lines
Added support to specify the AUTH_NONE security flavor (i.e. -o sec=none)
If you specify "-o sec=none" then data.pseudoflavor will == AUTH_NONE, but

This support is being added so that the client can mount a file system which was exported with sec=none.

Quoted 19 lines

Signed-off-by Steve Dickson <[email protected]>

utils/mount/nfsmount.c +2 -4

index d437036..7759260 100644
@@ -1093,12 +1093,14 @@ nfsmount(const char *spec, const char *node, int *flags,
 
 		flavor = mountres->auth_flavors.auth_flavors_val;
 		while (--i >= 0) {
-			if (flavor[i] == data.pseudoflavor)
-				yum = 1;
 #ifdef NFS_MOUNT_DEBUG
-			printf("auth flavor %d: %d\n",
-				i, flavor[i]);
+			printf("auth flavor[%d] %d\n", i, flavor[i]);
 #endif
+			if (flavor[i] == data.pseudoflavor ||

Quoted 8 lines

utils/mount/nfsmount.c nfsmount(const char *spec, const char *node, int *flags,
Quoted 5 lines
utils/mount/nfsmount.c +4 -0
+				flavor[i] == AUTH_NONE) {
+				yum = 1;
+				break;
+			}
 
You are testing if flavor[i] == AUTH_NONE, which doesn't make sense to me....

This loop is looking for AUTH_NONE in the list of authentication flavors that the server supports and was returned through the MOUNT protocol during mounting.

Basically, if the server file system is exported with AUTH_NONE, then it doesn't matter what flavor that the client chooses, the server will always map it to AUTH_NONE and all requests will be processed with the anonymous uid and gid.

ps

-------------------------------------------------------------------------
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Neil Brown

2007-02-28 23:09 UTC #3 lore raw

Quoted 10 lines · On Tuesday February 27, [email protected] wrote:

Quoted 9 lines · Neil Brown
Quoted 6 lines · On Monday February 26, [email protected] wrote:
commit 0ffd74c990aca3761b79316d47e1b1778273681c
Author: Steve Dickson <[email protected]>
Date:   Sat Feb 24 15:27:46 2007 -0500
Added support to specify the AUTH_NONE security flavor (i.e. -o sec=none)

Quoted 7 lines

Quoted 4 lines
If you specify "-o sec=none" then data.pseudoflavor will == AUTH_NONE, but
This support is being added so that the client can mount a file system which was exported with sec=none.

Ok, so the Changelog comment could be improved...

Quoted 9 lines

This loop is looking for AUTH_NONE in the list of authentication flavors that the server supports and was returned through the MOUNT protocol during mounting.
Basically, if the server file system is exported with AUTH_NONE, then it doesn't matter what flavor that the client chooses, the server will always map it to AUTH_NONE and all requests will be processed with the anonymous uid and gid.

I still don't understand (sorry if I am being dense). Surely a server could export a filesystem as AUTH_NONE or AUTH_UNIX or krbi. And it could matter a lot what auth the client uses because if it uses AUTH_NONE it would have access to many fewer files than e.g. AUTH_UNIX.

And surely if I mount with "-o sec=krbi", and the server only supports AUTH_NONE, then the mount should fail. But with the patch as given, I think it will succeed. What am I missing?

What exactly is the situation where the current code does the wrong thing, and the new code does the right thing?

Thanks,
NeilBrown

-------------------------------------------------------------------------
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Peter Staubach

2007-03-01 16:11 UTC #4 lore raw

Quoted 42 lines · Neil Brown

Quoted 12 lines · On Tuesday February 27, [email protected] wrote:
Quoted 10 lines · Neil Brown
Quoted 7 lines · On Monday February 26, [email protected] wrote:
commit 0ffd74c990aca3761b79316d47e1b1778273681c
Author: Steve Dickson <[email protected]>
Date:   Sat Feb 24 15:27:46 2007 -0500
Added support to specify the AUTH_NONE security flavor (i.e. -o sec=none)
Quoted 8 lines
Quoted 5 lines
If you specify "-o sec=none" then data.pseudoflavor will == AUTH_NONE, but
This support is being added so that the client can mount a file system which was exported with sec=none.
Ok, so the Changelog comment could be improved...
Quoted 9 lines
This loop is looking for AUTH_NONE in the list of authentication flavors that the server supports and was returned through the MOUNT protocol during mounting.
Basically, if the server file system is exported with AUTH_NONE, then it doesn't matter what flavor that the client chooses, the server will always map it to AUTH_NONE and all requests will be processed with the anonymous uid and gid.
I still don't understand (sorry if I am being dense). Surely a server could export a filesystem as AUTH_NONE or AUTH_UNIX or krbi. And it could matter a lot what auth the client uses because if it uses AUTH_NONE it would have access to many fewer files than e.g. AUTH_UNIX.

Quoted 6 lines

And surely if I mount with "-o sec=krbi", and the server only supports AUTH_NONE, then the mount should fail. But with the patch as given, I think it will succeed. What am I missing?
What exactly is the situation where the current code does the wrong thing, and the new code does the right thing?

The current code looks through the list of supported authentication flavors returned from the server and through its own list of supported flavors to try to find one that matches. Since the client does not support AUTH_NONE, then none match and the mount attempt fails.

Actually, the implementation appears to be that if the server exports with AUTH_NONE, then it will take any flavor of authentication on the incoming request, but then use AUTH_NONE for itself.

Since the server is exporting with AUTH_NONE, all incoming requests are processed using the anonymous uid and gid, and yes, should have reduced access.

This was used to address RH bz187370.

    Thanx...

       ps

-------------------------------------------------------------------------
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Neil Brown

2007-03-02 04:02 UTC #5 lore raw

Quoted 2 lines · On Thursday March 1, [email protected] wrote:

This was used to address RH bz187370.

Thanks for the link. It provides good context.

I would have thought the appropriate response would have been the following patch, and a suggestion to use
mount -o sec=none .....
to mount the filesystem.
Do you see a problem with that?

NeilBrown

utils/mount/nfsmount.c +3 -1

@@ -638,7 +638,9 @@ parse_options(char *old_opts, struct nfs_mount_data *data,
 				if (nfs_mount_version < 5) {
 					printf(_("Warning: ignoring sec=%s option\n"), secflavor);
 					continue;
-				} else if (!strcmp(secflavor, "sys"))
+				} else if (!strcmp(secflavor, "none"))
+					data->pseudoflavor = AUTH_NONE;
+				else if (!strcmp(secflavor, "sys"))
 					data->pseudoflavor = AUTH_SYS;
 				else if (!strcmp(secflavor, "krb5"))
 					data->pseudoflavor = AUTH_GSS_KRB5;

-------------------------------------------------------------------------
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Peter Staubach

2007-03-02 15:28 UTC #6 lore raw

Quoted 5 lines · Neil Brown

Quoted 2 lines · On Thursday March 1, [email protected] wrote:
This was used to address RH bz187370.

Quoted 7 lines

Thanks for the link. It provides good context.
I would have thought the appropriate response would have been the following patch, and a suggestion to use
mount -o sec=none .....
to mount the filesystem.
Do you see a problem with that?

Yes, that's not sufficient. The client should be able to automatically "do the right thing". The systems administrator shouldn't have to specify the authentication flavor to match the server flavor. That systems administrator should only have to specify when there are specific requirements for that client.

With this change, autofs would not be able correctly handle mounting this server via /net. It should be able to, especially since the server will accept _any_ flavor coming from the client.

And a question, I thought that I looked, and it did not appear that the kernel supported AUTH_NONE on the client side. Did I miss it?

    Thanx...

       ps

-------------------------------------------------------------------------
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Neil Brown

2007-03-13 05:49 UTC #7 lore raw

Quoted 14 lines · On Friday March 2, [email protected] wrote:

Quoted 5 lines · Neil Brown
Quoted 2 lines · On Thursday March 1, [email protected] wrote:
This was used to address RH bz187370.
Quoted 7 lines
Thanks for the link. It provides good context.
I would have thought the appropriate response would have been the following patch, and a suggestion to use
mount -o sec=none .....
to mount the filesystem.
Do you see a problem with that?

Quoted 5 lines

Yes, that's not sufficient. The client should be able to automatically "do the right thing". The systems administrator shouldn't have to specify the authentication flavor to match the server flavor. That systems administrator should only have to specify when there are specific requirements for that client.

Ok..... so maybe we want "-o sec=" to accept a list of flavours, with the default being "-o sec=sys:none". Would that be suitable? We would pick the first one in the server's list that is also in the clients list.
I'm not sure allowing a list to be specified is really needed, so the following patch just causes the default to be effectively sec=sys:none.
Would that suit?

I just really don't like the idea of sending NFS requests with AUTH_SYS when mountd has said that it only supports AUTH_NONE.

Quoted 3 lines

And a question, I thought that I looked, and it did not appear that the kernel supported AUTH_NONE on the client side. Did I miss it?

Well....
fs/nfs/super.c:nfs_pseudoflavour_to_name certainly recognises RPC_AUTH_NULL. and net/sunrpc/auth.c:auth_flavors has authnull_ops.
So I suspect the kernel supports it. I admit I haven't tried.

NeilBrown

utils/mount/nfsmount.c +9 -1

index f21c81c..eaf70f5 100644
@@ -902,7 +902,7 @@ nfsmount(const char *spec, const char *node, int *flags,
 #if NFS_MOUNT_VERSION >= 2
 	data.namlen	= NAME_MAX;
 #endif
-	data.pseudoflavor = AUTH_SYS;
+	data.pseudoflavor = -1; /* accept AUTH_SYS or AUTH_NONE */
 
 	bg = 0;
 	retry = 10000;		/* 10000 minutes ~ 1 week */

@@ -1090,6 +1090,14 @@ nfsmount(const char *spec, const char *node, int *flags,
 
 		flavor = mountres->auth_flavors.auth_flavors_val;
 		while (--i >= 0) {
+			/* If no flavour requests, use any simple
+			 * flavour that is offered.
+			 */
+			if (data.pseudoflavor == -1 &&
+			    (flavor[i] == AUTH_SYS ||
+			     flavor[i] == AUTH_NONE))
+				data.pseudoflavor = flavor[i];
+
 			if (flavor[i] == data.pseudoflavor)
 				yum = 1;
 #ifdef NFS_MOUNT_DEBUG

-------------------------------------------------------------------------
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Peter Staubach

2007-03-13 16:13 UTC #8 lore raw

Quoted 34 lines · Neil Brown

Quoted 16 lines · On Friday March 2, [email protected] wrote:
Quoted 6 lines · Neil Brown
Quoted 3 lines · On Thursday March 1, [email protected] wrote:
This was used to address RH bz187370.
Quoted 8 lines
Thanks for the link. It provides good context.
I would have thought the appropriate response would have been the following patch, and a suggestion to use
mount -o sec=none .....
to mount the filesystem.
Do you see a problem with that?
Quoted 6 lines
Yes, that's not sufficient. The client should be able to automatically "do the right thing". The systems administrator shouldn't have to specify the authentication flavor to match the server flavor. That systems administrator should only have to specify when there are specific requirements for that client.
Ok..... so maybe we want "-o sec=" to accept a list of flavours, with the default being "-o sec=sys:none". Would that be suitable? We would pick the first one in the server's list that is also in the clients list.
I'm not sure allowing a list to be specified is really needed, so the following patch just causes the default to be effectively sec=sys:none.
Would that suit?

Quoted 4 lines

I just really don't like the idea of sending NFS requests with AUTH_SYS when mountd has said that it only supports AUTH_NONE.

I have to admit that aesthetically, sending AUTH_SYS requests instead of AUTH_NONE seems inelegant, but it works and matches the behavior of other implementations.

Quoted 8 lines

Quoted 3 lines
And a question, I thought that I looked, and it did not appear that the kernel supported AUTH_NONE on the client side. Did I miss it?
Well....
fs/nfs/super.c:nfs_pseudoflavour_to_name certainly recognises RPC_AUTH_NULL. and net/sunrpc/auth.c:auth_flavors has authnull_ops.
So I suspect the kernel supports it. I admit I haven't tried.

With a small update to the patch, the kernel seems to _almost_ generate AUTH_NONE requests. Interestingly, the kernel makes the first FSINFO call with AUTH_SYS and then makes another FSINFO call with AUTH_NONE. Both FSINFO calls suceeded and returned the same information.

The small update to the patch is to add the line:

    data.flags |= NFS_MOUNT_SECFLAVOUR;

after setting data.pseudoflavor to flavor[i].

Anyone know why, off hand, the NFS client needs to make two FSINFO calls?

    Thanx...

       ps

-------------------------------------------------------------------------
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Neil Brown

2007-03-14 22:47 UTC #9 lore raw

Quoted 6 lines · On Tuesday March 13, [email protected] wrote:

The small update to the patch is to add the line:
    data.flags |= NFS_MOUNT_SECFLAVOUR;
after setting data.pseudoflavor to flavor[i].

Thanks... That implies that I don't need the (rather ugly) -1 value to say "nothing requested". I can just test this flag and set data.pseudoflavor to flavor[i] if it isn't set.

Thanks.

Quoted 3 lines

Anyone know why, off hand, the NFS client needs to make two FSINFO calls?

Not me, know...

NeilBrown

-------------------------------------------------------------------------
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs