[PATCH] NFS: Change default behavior when "sec=" is not specified by user

[PATCH] NFS: Change default behavior when "sec=" is not specified by user

[Chuck Lever]

Currently the kernel's MNT client always uses AUTH_UNIX if no "sec="
mount option was specified.  In the interest of conforming more
closely to RFC 2623, teach the MNT client to use the first flavor on
the server's returned authflavor list instead of AUTH_UNIX, if "sec="
was not specified.

When the user does not specify "sec=" :

 o  For NFSv2 and NFSv4: the default is always AUTH_UNIX (unchanged).

 o  For NFSv3: if the server does not return an auth flavor list, use
    AUTH_UNIX by default; if the server does return a list, use the
    first entry on the list by default.

See http://marc.info/?t=125075305400001&r=1&w=2 .

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
---

Trond, Bruce-

Based on last week's e-mail discussion, maybe this should also be
included in 2.6.32?

 fs/nfs/super.c                  |   38 ++++++++++++++++++++++++++------------
 include/linux/sunrpc/msg_prot.h |    2 ++
 2 files changed, 28 insertions(+), 12 deletions(-)

diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index bde444b..5165847 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -1380,19 +1380,25 @@ static int nfs_walk_authlist(struct nfs_parsed_mount_data *args,
 	 * succeed), revert to pre-2.6.32 behavior (no checking)
 	 * if the returned flavor list is empty.
 	 */
-	if (server_authlist_len == 0)
+	if (server_authlist_len == 0) {
+		if (args->auth_flavors[0] == RPC_AUTH_UNSPEC)
+			args->auth_flavors[0] = RPC_AUTH_UNIX;
 		return 0;
+	}
 
 	/*
-	 * We avoid sophisticated negotiating here, as there are
-	 * plenty of cases where we can get it wrong, providing
-	 * either too little or too much security.
-	 *
 	 * RFC 2623, section 2.7 suggests we SHOULD prefer the
-	 * flavor listed first.  However, some servers list
-	 * AUTH_NULL first.  Our caller plants AUTH_SYS, the
-	 * preferred default, in args->auth_flavors[0] if user
-	 * didn't specify sec= mount option.
+	 * first flavor on the list if the user did not request
+	 * a specific flavor.
+	 */
+	if (args->auth_flavors[0] == RPC_AUTH_UNSPEC) {
+		args->auth_flavors[0] = request->auth_flavs[0];
+		return 0;
+	}
+
+	/*
+	 * Otherwise, check if the user-specified flavor is on the
+	 * server's list, and fail the mount if it is not found.
 	 */
 	for (i = 0; i < args->auth_flavor_len; i++)
 		for (j = 0; j < server_authlist_len; j++)
@@ -1467,8 +1473,12 @@ static int nfs_try_mount(struct nfs_parsed_mount_data *args,
 	/*
 	 * MNTv1 (NFSv2) does not support auth flavor negotiation.
 	 */
-	if (args->mount_server.version != NFS_MNT3_VERSION)
+	if (args->mount_server.version != NFS_MNT3_VERSION) {
+		if (args->auth_flavors[0] == RPC_AUTH_UNSPEC)
+			args->auth_flavors[0] = RPC_AUTH_UNIX;
 		return 0;
+	}
+
 	return nfs_walk_authlist(args, &request);
 }
 
@@ -1644,7 +1654,7 @@ static int nfs_validate_mount_data(void *options,
 	args->mount_server.port	= NFS_UNSPEC_PORT;
 	args->nfs_server.port	= NFS_UNSPEC_PORT;
 	args->nfs_server.protocol = XPRT_TRANSPORT_TCP;
-	args->auth_flavors[0]	= RPC_AUTH_UNIX;
+	args->auth_flavors[0]	= RPC_AUTH_UNSPEC;
 	args->auth_flavor_len	= 1;
 	args->minorversion	= 0;
 
@@ -1703,6 +1713,7 @@ static int nfs_validate_mount_data(void *options,
 		args->namlen		= data->namlen;
 		args->bsize		= data->bsize;
 
+		args->auth_flavors[0] = RPC_AUTH_UNIX;
 		if (data->flags & NFS_MOUNT_SECFLAVOUR)
 			args->auth_flavors[0] = data->pseudoflavor;
 		if (!args->nfs_server.hostname)
@@ -2323,6 +2334,8 @@ static int nfs4_validate_text_mount_data(void *options,
 			 "NFS4: Too many RPC auth flavours specified\n");
 		return -EINVAL;
 	}
+	if (args->auth_flavors[0] == RPC_AUTH_UNSPEC)
+		args->auth_flavors[0] = RPC_AUTH_UNIX;
 
 	if (args->client_address == NULL) {
 		dfprintk(MOUNT,
@@ -2358,7 +2371,7 @@ static int nfs4_validate_mount_data(void *options,
 	args->acdirmin		= NFS_DEF_ACDIRMIN;
 	args->acdirmax		= NFS_DEF_ACDIRMAX;
 	args->nfs_server.port	= NFS_UNSPEC_PORT;
-	args->auth_flavors[0]	= RPC_AUTH_UNIX;
+	args->auth_flavors[0]	= RPC_AUTH_UNSPEC;
 	args->auth_flavor_len	= 1;
 	args->minorversion	= 0;
 
@@ -2374,6 +2387,7 @@ static int nfs4_validate_mount_data(void *options,
 		if (!nfs_verify_server_address(sap))
 			goto out_no_address;
 
+		args->auth_flavors[0] = RPC_AUTH_UNIX;
 		if (data->auth_flavourlen) {
 			if (data->auth_flavourlen > 1)
 				goto out_inval_auth;
diff --git a/include/linux/sunrpc/msg_prot.h b/include/linux/sunrpc/msg_prot.h
index 77e6248..7d6d3ed 100644
--- a/include/linux/sunrpc/msg_prot.h
+++ b/include/linux/sunrpc/msg_prot.h
@@ -35,6 +35,8 @@ enum rpc_auth_flavors {
 	RPC_AUTH_GSS_SPKM  = 390009,
 	RPC_AUTH_GSS_SPKMI = 390010,
 	RPC_AUTH_GSS_SPKMP = 390011,
+	/* flavor was unspecified: */
+	RPC_AUTH_UNSPEC = 0xffffffff,
 };
 
 /* Maximum size (in bytes) of an rpc credential or verifier */

Re: [PATCH] NFS: Change default behavior when "sec=" is not specified by user

[J. Bruce Fields]

On Tue, Sep 01, 2009 at 10:31:38AM -0400, Chuck Lever wrote:
> Currently the kernel's MNT client always uses AUTH_UNIX if no "sec="
> mount option was specified.  In the interest of conforming more
> closely to RFC 2623, teach the MNT client to use the first flavor on
> the server's returned authflavor list instead of AUTH_UNIX, if "sec="
> was not specified.
> 
> When the user does not specify "sec=" :
> 
>  o  For NFSv2 and NFSv4: the default is always AUTH_UNIX (unchanged).
> 
>  o  For NFSv3: if the server does not return an auth flavor list, use
>     AUTH_UNIX by default; if the server does return a list, use the
>     first entry on the list by default.

Sounds good, but also:

	1. Even when sec= is provided, we should probably still check
	the passed-in security against the server-returned list.
	(Otherwise AUTH_NULL mounts will almost *always* succeed, even
	when no subsequent file operation would, thanks to the
	allow-AUTH_NULL-on-mount behavior recommended by rfc 2523).
	http://marc.info/?l=linux-nfs&m=125088837303339&w=2

	2. In the absence of sec=, we should probably *not* choose
	AUTH_NULL.  (All mountd's before 1.1.3 list AUTH_NULL first on
	the returned list, so users with older servers may wonder why a
	client upgrade is making files they create suddenly be owned by
	nobody.) http://marc.info/?l=linux-nfs&m=125089022306281&w=2

	3. As a special exception, we should probably allow an explicit
	"sec=null" to override #1 above, since ommission of AUTH_NULL
	from post-1.1.3 mountd returns will make it otherwise impossible
	to mount with AUTH_NULL.
	http://marc.info/?l=linux-nfs&m=125113569524411&w=2

Oops, my bad: I see now from the code that you did actually do #1, you
just didn't mention it above.  OK!

I don't see #2 or #3, though maybe they're already handled somewhere....

--b.

> 
> See http://marc.info/?t=125075305400001&r=1&w=2 .
> 
> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
> ---
> 
> Trond, Bruce-
> 
> Based on last week's e-mail discussion, maybe this should also be
> included in 2.6.32?
> 
>  fs/nfs/super.c                  |   38 ++++++++++++++++++++++++++------------
>  include/linux/sunrpc/msg_prot.h |    2 ++
>  2 files changed, 28 insertions(+), 12 deletions(-)
> 
> diff --git a/fs/nfs/super.c b/fs/nfs/super.c
> index bde444b..5165847 100644
> --- a/fs/nfs/super.c
> +++ b/fs/nfs/super.c
> @@ -1380,19 +1380,25 @@ static int nfs_walk_authlist(struct nfs_parsed_mount_data *args,
>  	 * succeed), revert to pre-2.6.32 behavior (no checking)
>  	 * if the returned flavor list is empty.
>  	 */
> -	if (server_authlist_len == 0)
> +	if (server_authlist_len == 0) {
> +		if (args->auth_flavors[0] == RPC_AUTH_UNSPEC)
> +			args->auth_flavors[0] = RPC_AUTH_UNIX;
>  		return 0;
> +	}
>  
>  	/*
> -	 * We avoid sophisticated negotiating here, as there are
> -	 * plenty of cases where we can get it wrong, providing
> -	 * either too little or too much security.
> -	 *
>  	 * RFC 2623, section 2.7 suggests we SHOULD prefer the
> -	 * flavor listed first.  However, some servers list
> -	 * AUTH_NULL first.  Our caller plants AUTH_SYS, the
> -	 * preferred default, in args->auth_flavors[0] if user
> -	 * didn't specify sec= mount option.
> +	 * first flavor on the list if the user did not request
> +	 * a specific flavor.
> +	 */
> +	if (args->auth_flavors[0] == RPC_AUTH_UNSPEC) {
> +		args->auth_flavors[0] = request->auth_flavs[0];
> +		return 0;
> +	}
> +
> +	/*
> +	 * Otherwise, check if the user-specified flavor is on the
> +	 * server's list, and fail the mount if it is not found.
>  	 */
>  	for (i = 0; i < args->auth_flavor_len; i++)
>  		for (j = 0; j < server_authlist_len; j++)
> @@ -1467,8 +1473,12 @@ static int nfs_try_mount(struct nfs_parsed_mount_data *args,
>  	/*
>  	 * MNTv1 (NFSv2) does not support auth flavor negotiation.
>  	 */
> -	if (args->mount_server.version != NFS_MNT3_VERSION)
> +	if (args->mount_server.version != NFS_MNT3_VERSION) {
> +		if (args->auth_flavors[0] == RPC_AUTH_UNSPEC)
> +			args->auth_flavors[0] = RPC_AUTH_UNIX;
>  		return 0;
> +	}
> +
>  	return nfs_walk_authlist(args, &request);
>  }
>  
> @@ -1644,7 +1654,7 @@ static int nfs_validate_mount_data(void *options,
>  	args->mount_server.port	= NFS_UNSPEC_PORT;
>  	args->nfs_server.port	= NFS_UNSPEC_PORT;
>  	args->nfs_server.protocol = XPRT_TRANSPORT_TCP;
> -	args->auth_flavors[0]	= RPC_AUTH_UNIX;
> +	args->auth_flavors[0]	= RPC_AUTH_UNSPEC;
>  	args->auth_flavor_len	= 1;
>  	args->minorversion	= 0;
>  
> @@ -1703,6 +1713,7 @@ static int nfs_validate_mount_data(void *options,
>  		args->namlen		= data->namlen;
>  		args->bsize		= data->bsize;
>  
> +		args->auth_flavors[0] = RPC_AUTH_UNIX;
>  		if (data->flags & NFS_MOUNT_SECFLAVOUR)
>  			args->auth_flavors[0] = data->pseudoflavor;
>  		if (!args->nfs_server.hostname)
> @@ -2323,6 +2334,8 @@ static int nfs4_validate_text_mount_data(void *options,
>  			 "NFS4: Too many RPC auth flavours specified\n");
>  		return -EINVAL;
>  	}
> +	if (args->auth_flavors[0] == RPC_AUTH_UNSPEC)
> +		args->auth_flavors[0] = RPC_AUTH_UNIX;
>  
>  	if (args->client_address == NULL) {
>  		dfprintk(MOUNT,
> @@ -2358,7 +2371,7 @@ static int nfs4_validate_mount_data(void *options,
>  	args->acdirmin		= NFS_DEF_ACDIRMIN;
>  	args->acdirmax		= NFS_DEF_ACDIRMAX;
>  	args->nfs_server.port	= NFS_UNSPEC_PORT;
> -	args->auth_flavors[0]	= RPC_AUTH_UNIX;
> +	args->auth_flavors[0]	= RPC_AUTH_UNSPEC;
>  	args->auth_flavor_len	= 1;
>  	args->minorversion	= 0;
>  
> @@ -2374,6 +2387,7 @@ static int nfs4_validate_mount_data(void *options,
>  		if (!nfs_verify_server_address(sap))
>  			goto out_no_address;
>  
> +		args->auth_flavors[0] = RPC_AUTH_UNIX;
>  		if (data->auth_flavourlen) {
>  			if (data->auth_flavourlen > 1)
>  				goto out_inval_auth;
> diff --git a/include/linux/sunrpc/msg_prot.h b/include/linux/sunrpc/msg_prot.h
> index 77e6248..7d6d3ed 100644
> --- a/include/linux/sunrpc/msg_prot.h
> +++ b/include/linux/sunrpc/msg_prot.h
> @@ -35,6 +35,8 @@ enum rpc_auth_flavors {
>  	RPC_AUTH_GSS_SPKM  = 390009,
>  	RPC_AUTH_GSS_SPKMI = 390010,
>  	RPC_AUTH_GSS_SPKMP = 390011,
> +	/* flavor was unspecified: */
> +	RPC_AUTH_UNSPEC = 0xffffffff,
>  };
>  
>  /* Maximum size (in bytes) of an rpc credential or verifier */
> 

Re: [PATCH] NFS: Change default behavior when "sec=" is not specified by user

[Chuck Lever]

On Sep 1, 2009, at 11:05 AM, J. Bruce Fields wrote:
> On Tue, Sep 01, 2009 at 10:31:38AM -0400, Chuck Lever wrote:
>> Currently the kernel's MNT client always uses AUTH_UNIX if no "sec="
>> mount option was specified.  In the interest of conforming more
>> closely to RFC 2623, teach the MNT client to use the first flavor on
>> the server's returned authflavor list instead of AUTH_UNIX, if "sec="
>> was not specified.
>>
>> When the user does not specify "sec=" :
>>
>> o  For NFSv2 and NFSv4: the default is always AUTH_UNIX (unchanged).
>>
>> o  For NFSv3: if the server does not return an auth flavor list, use
>>    AUTH_UNIX by default; if the server does return a list, use the
>>    first entry on the list by default.
>
> Sounds good, but also:
>
> 	1. Even when sec= is provided, we should probably still check
> 	the passed-in security against the server-returned list.
> 	(Otherwise AUTH_NULL mounts will almost *always* succeed, even
> 	when no subsequent file operation would, thanks to the
> 	allow-AUTH_NULL-on-mount behavior recommended by rfc 2523).
> 	http://marc.info/?l=linux-nfs&m=125088837303339&w=2
>
> 	2. In the absence of sec=, we should probably *not* choose
> 	AUTH_NULL.  (All mountd's before 1.1.3 list AUTH_NULL first on
> 	the returned list, so users with older servers may wonder why a
> 	client upgrade is making files they create suddenly be owned by
> 	nobody.) http://marc.info/?l=linux-nfs&m=125089022306281&w=2
>
> 	3. As a special exception, we should probably allow an explicit
> 	"sec=null" to override #1 above, since ommission of AUTH_NULL
> 	from post-1.1.3 mountd returns will make it otherwise impossible
> 	to mount with AUTH_NULL.
> 	http://marc.info/?l=linux-nfs&m=125113569524411&w=2
>
> Oops, my bad: I see now from the code that you did actually do #1, you
> just didn't mention it above.  OK!
>
> I don't see #2 or #3, though maybe they're already handled  
> somewhere....

No, not in the kernel's MNT client.  #3 seems like a server bug to me,  
though.

> --b.
>
>>
>> See http://marc.info/?t=125075305400001&r=1&w=2 .
>>
>> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
>> ---
>>
>> Trond, Bruce-
>>
>> Based on last week's e-mail discussion, maybe this should also be
>> included in 2.6.32?
>>
>> fs/nfs/super.c                  |   38 +++++++++++++++++++++++++ 
>> +------------
>> include/linux/sunrpc/msg_prot.h |    2 ++
>> 2 files changed, 28 insertions(+), 12 deletions(-)
>>
>> diff --git a/fs/nfs/super.c b/fs/nfs/super.c
>> index bde444b..5165847 100644
>> --- a/fs/nfs/super.c
>> +++ b/fs/nfs/super.c
>> @@ -1380,19 +1380,25 @@ static int nfs_walk_authlist(struct  
>> nfs_parsed_mount_data *args,
>> 	 * succeed), revert to pre-2.6.32 behavior (no checking)
>> 	 * if the returned flavor list is empty.
>> 	 */
>> -	if (server_authlist_len == 0)
>> +	if (server_authlist_len == 0) {
>> +		if (args->auth_flavors[0] == RPC_AUTH_UNSPEC)
>> +			args->auth_flavors[0] = RPC_AUTH_UNIX;
>> 		return 0;
>> +	}
>>
>> 	/*
>> -	 * We avoid sophisticated negotiating here, as there are
>> -	 * plenty of cases where we can get it wrong, providing
>> -	 * either too little or too much security.
>> -	 *
>> 	 * RFC 2623, section 2.7 suggests we SHOULD prefer the
>> -	 * flavor listed first.  However, some servers list
>> -	 * AUTH_NULL first.  Our caller plants AUTH_SYS, the
>> -	 * preferred default, in args->auth_flavors[0] if user
>> -	 * didn't specify sec= mount option.
>> +	 * first flavor on the list if the user did not request
>> +	 * a specific flavor.
>> +	 */
>> +	if (args->auth_flavors[0] == RPC_AUTH_UNSPEC) {
>> +		args->auth_flavors[0] = request->auth_flavs[0];
>> +		return 0;
>> +	}
>> +
>> +	/*
>> +	 * Otherwise, check if the user-specified flavor is on the
>> +	 * server's list, and fail the mount if it is not found.
>> 	 */
>> 	for (i = 0; i < args->auth_flavor_len; i++)
>> 		for (j = 0; j < server_authlist_len; j++)
>> @@ -1467,8 +1473,12 @@ static int nfs_try_mount(struct  
>> nfs_parsed_mount_data *args,
>> 	/*
>> 	 * MNTv1 (NFSv2) does not support auth flavor negotiation.
>> 	 */
>> -	if (args->mount_server.version != NFS_MNT3_VERSION)
>> +	if (args->mount_server.version != NFS_MNT3_VERSION) {
>> +		if (args->auth_flavors[0] == RPC_AUTH_UNSPEC)
>> +			args->auth_flavors[0] = RPC_AUTH_UNIX;
>> 		return 0;
>> +	}
>> +
>> 	return nfs_walk_authlist(args, &request);
>> }
>>
>> @@ -1644,7 +1654,7 @@ static int nfs_validate_mount_data(void  
>> *options,
>> 	args->mount_server.port	= NFS_UNSPEC_PORT;
>> 	args->nfs_server.port	= NFS_UNSPEC_PORT;
>> 	args->nfs_server.protocol = XPRT_TRANSPORT_TCP;
>> -	args->auth_flavors[0]	= RPC_AUTH_UNIX;
>> +	args->auth_flavors[0]	= RPC_AUTH_UNSPEC;
>> 	args->auth_flavor_len	= 1;
>> 	args->minorversion	= 0;
>>
>> @@ -1703,6 +1713,7 @@ static int nfs_validate_mount_data(void  
>> *options,
>> 		args->namlen		= data->namlen;
>> 		args->bsize		= data->bsize;
>>
>> +		args->auth_flavors[0] = RPC_AUTH_UNIX;
>> 		if (data->flags & NFS_MOUNT_SECFLAVOUR)
>> 			args->auth_flavors[0] = data->pseudoflavor;
>> 		if (!args->nfs_server.hostname)
>> @@ -2323,6 +2334,8 @@ static int nfs4_validate_text_mount_data(void  
>> *options,
>> 			 "NFS4: Too many RPC auth flavours specified\n");
>> 		return -EINVAL;
>> 	}
>> +	if (args->auth_flavors[0] == RPC_AUTH_UNSPEC)
>> +		args->auth_flavors[0] = RPC_AUTH_UNIX;
>>
>> 	if (args->client_address == NULL) {
>> 		dfprintk(MOUNT,
>> @@ -2358,7 +2371,7 @@ static int nfs4_validate_mount_data(void  
>> *options,
>> 	args->acdirmin		= NFS_DEF_ACDIRMIN;
>> 	args->acdirmax		= NFS_DEF_ACDIRMAX;
>> 	args->nfs_server.port	= NFS_UNSPEC_PORT;
>> -	args->auth_flavors[0]	= RPC_AUTH_UNIX;
>> +	args->auth_flavors[0]	= RPC_AUTH_UNSPEC;
>> 	args->auth_flavor_len	= 1;
>> 	args->minorversion	= 0;
>>
>> @@ -2374,6 +2387,7 @@ static int nfs4_validate_mount_data(void  
>> *options,
>> 		if (!nfs_verify_server_address(sap))
>> 			goto out_no_address;
>>
>> +		args->auth_flavors[0] = RPC_AUTH_UNIX;
>> 		if (data->auth_flavourlen) {
>> 			if (data->auth_flavourlen > 1)
>> 				goto out_inval_auth;
>> diff --git a/include/linux/sunrpc/msg_prot.h b/include/linux/sunrpc/ 
>> msg_prot.h
>> index 77e6248..7d6d3ed 100644
>> --- a/include/linux/sunrpc/msg_prot.h
>> +++ b/include/linux/sunrpc/msg_prot.h
>> @@ -35,6 +35,8 @@ enum rpc_auth_flavors {
>> 	RPC_AUTH_GSS_SPKM  = 390009,
>> 	RPC_AUTH_GSS_SPKMI = 390010,
>> 	RPC_AUTH_GSS_SPKMP = 390011,
>> +	/* flavor was unspecified: */
>> +	RPC_AUTH_UNSPEC = 0xffffffff,
>> };
>>
>> /* Maximum size (in bytes) of an rpc credential or verifier */
>>

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: [PATCH] NFS: Change default behavior when "sec=" is not specified by user

[J. Bruce Fields]

On Tue, Sep 01, 2009 at 11:10:36AM -0400, Chuck Lever wrote:
> On Sep 1, 2009, at 11:05 AM, J. Bruce Fields wrote:
>> On Tue, Sep 01, 2009 at 10:31:38AM -0400, Chuck Lever wrote:
>>> Currently the kernel's MNT client always uses AUTH_UNIX if no "sec="
>>> mount option was specified.  In the interest of conforming more
>>> closely to RFC 2623, teach the MNT client to use the first flavor on
>>> the server's returned authflavor list instead of AUTH_UNIX, if "sec="
>>> was not specified.
>>>
>>> When the user does not specify "sec=" :
>>>
>>> o  For NFSv2 and NFSv4: the default is always AUTH_UNIX (unchanged).
>>>
>>> o  For NFSv3: if the server does not return an auth flavor list, use
>>>    AUTH_UNIX by default; if the server does return a list, use the
>>>    first entry on the list by default.
>>
>> Sounds good, but also:
>>
>> 	1. Even when sec= is provided, we should probably still check
>> 	the passed-in security against the server-returned list.
>> 	(Otherwise AUTH_NULL mounts will almost *always* succeed, even
>> 	when no subsequent file operation would, thanks to the
>> 	allow-AUTH_NULL-on-mount behavior recommended by rfc 2523).
>> 	http://marc.info/?l=linux-nfs&m=125088837303339&w=2
>>
>> 	2. In the absence of sec=, we should probably *not* choose
>> 	AUTH_NULL.  (All mountd's before 1.1.3 list AUTH_NULL first on
>> 	the returned list, so users with older servers may wonder why a
>> 	client upgrade is making files they create suddenly be owned by
>> 	nobody.) http://marc.info/?l=linux-nfs&m=125089022306281&w=2
>>
>> 	3. As a special exception, we should probably allow an explicit
>> 	"sec=null" to override #1 above, since ommission of AUTH_NULL
>> 	from post-1.1.3 mountd returns will make it otherwise impossible
>> 	to mount with AUTH_NULL.
>> 	http://marc.info/?l=linux-nfs&m=125113569524411&w=2
>>
>> Oops, my bad: I see now from the code that you did actually do #1, you
>> just didn't mention it above.  OK!
>>
>> I don't see #2 or #3, though maybe they're already handled  
>> somewhere....
>
> No, not in the kernel's MNT client.  #3 seems like a server bug to me,  
> though.

Alas, it's apparently a workaround for a client bug: see the url
referenced after #3.  (But I don't know what client versions that bug
was in.  If someone investigated and found they weren't widely
distributed, I'd take a patch to remove the workaround.)

--b.

Re: [PATCH] NFS: Change default behavior when "sec=" is not specified by user

[Chuck Lever]

On Sep 1, 2009, at 11:18 AM, J. Bruce Fields wrote:

> On Tue, Sep 01, 2009 at 11:10:36AM -0400, Chuck Lever wrote:
>> On Sep 1, 2009, at 11:05 AM, J. Bruce Fields wrote:
>>> On Tue, Sep 01, 2009 at 10:31:38AM -0400, Chuck Lever wrote:
>>>> Currently the kernel's MNT client always uses AUTH_UNIX if no  
>>>> "sec="
>>>> mount option was specified.  In the interest of conforming more
>>>> closely to RFC 2623, teach the MNT client to use the first flavor  
>>>> on
>>>> the server's returned authflavor list instead of AUTH_UNIX, if  
>>>> "sec="
>>>> was not specified.
>>>>
>>>> When the user does not specify "sec=" :
>>>>
>>>> o  For NFSv2 and NFSv4: the default is always AUTH_UNIX  
>>>> (unchanged).
>>>>
>>>> o  For NFSv3: if the server does not return an auth flavor list,  
>>>> use
>>>>   AUTH_UNIX by default; if the server does return a list, use the
>>>>   first entry on the list by default.
>>>
>>> Sounds good, but also:
>>>
>>> 	1. Even when sec= is provided, we should probably still check
>>> 	the passed-in security against the server-returned list.
>>> 	(Otherwise AUTH_NULL mounts will almost *always* succeed, even
>>> 	when no subsequent file operation would, thanks to the
>>> 	allow-AUTH_NULL-on-mount behavior recommended by rfc 2523).
>>> 	http://marc.info/?l=linux-nfs&m=125088837303339&w=2
>>>
>>> 	2. In the absence of sec=, we should probably *not* choose
>>> 	AUTH_NULL.  (All mountd's before 1.1.3 list AUTH_NULL first on
>>> 	the returned list, so users with older servers may wonder why a
>>> 	client upgrade is making files they create suddenly be owned by
>>> 	nobody.) http://marc.info/?l=linux-nfs&m=125089022306281&w=2
>>>
>>> 	3. As a special exception, we should probably allow an explicit
>>> 	"sec=null" to override #1 above, since ommission of AUTH_NULL
>>> 	from post-1.1.3 mountd returns will make it otherwise impossible
>>> 	to mount with AUTH_NULL.
>>> 	http://marc.info/?l=linux-nfs&m=125113569524411&w=2
>>>
>>> Oops, my bad: I see now from the code that you did actually do #1,  
>>> you
>>> just didn't mention it above.  OK!
>>>
>>> I don't see #2 or #3, though maybe they're already handled
>>> somewhere....
>>
>> No, not in the kernel's MNT client.  #3 seems like a server bug to  
>> me,
>> though.
>
> Alas, it's apparently a workaround for a client bug: see the url
> referenced after #3.  (But I don't know what client versions that bug
> was in.  If someone investigated and found they weren't widely
> distributed, I'd take a patch to remove the workaround.)

How are clients supposed to tell if the server actually supports  
AUTH_NULL but didn't list it, versus the admin specifically forbidding  
the use of AUTH_NULL?

Mountd should list AUTH_NULL if the server admin specified it  
(although it doesn't need to list AUTH_NULL by default).  The server  
is allowed to reorder the flavor list, not the client, according to  
RFC 2623.  The server's admin may even _prefer_ "rw,sec=null" access,  
in which case listing AUTH_NULL first is actually desired.

That's my thinking, anyway.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: [PATCH] NFS: Change default behavior when "sec=" is not specified by user

[J. Bruce Fields]

On Tue, Sep 01, 2009 at 11:52:39AM -0400, Chuck Lever wrote:
>
> On Sep 1, 2009, at 11:18 AM, J. Bruce Fields wrote:
>
>> On Tue, Sep 01, 2009 at 11:10:36AM -0400, Chuck Lever wrote:
>>> On Sep 1, 2009, at 11:05 AM, J. Bruce Fields wrote:
>>>> On Tue, Sep 01, 2009 at 10:31:38AM -0400, Chuck Lever wrote:
>>>>> Currently the kernel's MNT client always uses AUTH_UNIX if no  
>>>>> "sec="
>>>>> mount option was specified.  In the interest of conforming more
>>>>> closely to RFC 2623, teach the MNT client to use the first flavor 
>>>>> on
>>>>> the server's returned authflavor list instead of AUTH_UNIX, if  
>>>>> "sec="
>>>>> was not specified.
>>>>>
>>>>> When the user does not specify "sec=" :
>>>>>
>>>>> o  For NFSv2 and NFSv4: the default is always AUTH_UNIX  
>>>>> (unchanged).
>>>>>
>>>>> o  For NFSv3: if the server does not return an auth flavor list,  
>>>>> use
>>>>>   AUTH_UNIX by default; if the server does return a list, use the
>>>>>   first entry on the list by default.
>>>>
>>>> Sounds good, but also:
>>>>
>>>> 	1. Even when sec= is provided, we should probably still check
>>>> 	the passed-in security against the server-returned list.
>>>> 	(Otherwise AUTH_NULL mounts will almost *always* succeed, even
>>>> 	when no subsequent file operation would, thanks to the
>>>> 	allow-AUTH_NULL-on-mount behavior recommended by rfc 2523).
>>>> 	http://marc.info/?l=linux-nfs&m=125088837303339&w=2
>>>>
>>>> 	2. In the absence of sec=, we should probably *not* choose
>>>> 	AUTH_NULL.  (All mountd's before 1.1.3 list AUTH_NULL first on
>>>> 	the returned list, so users with older servers may wonder why a
>>>> 	client upgrade is making files they create suddenly be owned by
>>>> 	nobody.) http://marc.info/?l=linux-nfs&m=125089022306281&w=2
>>>>
>>>> 	3. As a special exception, we should probably allow an explicit
>>>> 	"sec=null" to override #1 above, since ommission of AUTH_NULL
>>>> 	from post-1.1.3 mountd returns will make it otherwise impossible
>>>> 	to mount with AUTH_NULL.
>>>> 	http://marc.info/?l=linux-nfs&m=125113569524411&w=2
>>>>
>>>> Oops, my bad: I see now from the code that you did actually do #1,  
>>>> you
>>>> just didn't mention it above.  OK!
>>>>
>>>> I don't see #2 or #3, though maybe they're already handled
>>>> somewhere....
>>>
>>> No, not in the kernel's MNT client.  #3 seems like a server bug to  
>>> me,
>>> though.
>>
>> Alas, it's apparently a workaround for a client bug: see the url
>> referenced after #3.  (But I don't know what client versions that bug
>> was in.  If someone investigated and found they weren't widely
>> distributed, I'd take a patch to remove the workaround.)
>
> How are clients supposed to tell if the server actually supports  
> AUTH_NULL but didn't list it, versus the admin specifically forbidding  
> the use of AUTH_NULL?

They can't.  So the compromise I proposed was to avoid negotiating
AUTH_NULL automatically, but to allow the user's explicit sec=null to
override the server's returned list.  That said, I think I'm convinced:

> Mountd should list AUTH_NULL if the server admin specified it (although 
> it doesn't need to list AUTH_NULL by default).  The server is allowed to 
> reorder the flavor list, not the client, according to RFC 2623.  The 
> server's admin may even _prefer_ "rw,sec=null" access, in which case 
> listing AUTH_NULL first is actually desired.

And in fact that's the way a recent linux server works.

So if you do #2 above but not #3, then you can tell people: if you
really need auth_null, you need to a) request it explicitly on the mount
commandline, b) upgrade to a recent mountd (at least 1.1.4), and c) list
it explicitly on the server export.

And, sure, that'd be OK with me, and would probably be better than
adding another exception, so I'm OK with skipping #3.  (We definitely
shouldn't omit #2, though.)

--b.

Re: [PATCH] NFS: Change default behavior when "sec=" is not specified by user

[Chuck Lever]

On Sep 1, 2009, at 12:09 PM, J. Bruce Fields wrote:
> On Tue, Sep 01, 2009 at 11:52:39AM -0400, Chuck Lever wrote:
>>
>> On Sep 1, 2009, at 11:18 AM, J. Bruce Fields wrote:
>>
>>> On Tue, Sep 01, 2009 at 11:10:36AM -0400, Chuck Lever wrote:
>>>> On Sep 1, 2009, at 11:05 AM, J. Bruce Fields wrote:
>>>>> On Tue, Sep 01, 2009 at 10:31:38AM -0400, Chuck Lever wrote:
>>>>>> Currently the kernel's MNT client always uses AUTH_UNIX if no
>>>>>> "sec="
>>>>>> mount option was specified.  In the interest of conforming more
>>>>>> closely to RFC 2623, teach the MNT client to use the first flavor
>>>>>> on
>>>>>> the server's returned authflavor list instead of AUTH_UNIX, if
>>>>>> "sec="
>>>>>> was not specified.
>>>>>>
>>>>>> When the user does not specify "sec=" :
>>>>>>
>>>>>> o  For NFSv2 and NFSv4: the default is always AUTH_UNIX
>>>>>> (unchanged).
>>>>>>
>>>>>> o  For NFSv3: if the server does not return an auth flavor list,
>>>>>> use
>>>>>>  AUTH_UNIX by default; if the server does return a list, use the
>>>>>>  first entry on the list by default.
>>>>>
>>>>> Sounds good, but also:
>>>>>
>>>>> 	1. Even when sec= is provided, we should probably still check
>>>>> 	the passed-in security against the server-returned list.
>>>>> 	(Otherwise AUTH_NULL mounts will almost *always* succeed, even
>>>>> 	when no subsequent file operation would, thanks to the
>>>>> 	allow-AUTH_NULL-on-mount behavior recommended by rfc 2523).
>>>>> 	http://marc.info/?l=linux-nfs&m=125088837303339&w=2
>>>>>
>>>>> 	2. In the absence of sec=, we should probably *not* choose
>>>>> 	AUTH_NULL.  (All mountd's before 1.1.3 list AUTH_NULL first on
>>>>> 	the returned list, so users with older servers may wonder why a
>>>>> 	client upgrade is making files they create suddenly be owned by
>>>>> 	nobody.) http://marc.info/?l=linux-nfs&m=125089022306281&w=2
>>>>>
>>>>> 	3. As a special exception, we should probably allow an explicit
>>>>> 	"sec=null" to override #1 above, since ommission of AUTH_NULL
>>>>> 	from post-1.1.3 mountd returns will make it otherwise impossible
>>>>> 	to mount with AUTH_NULL.
>>>>> 	http://marc.info/?l=linux-nfs&m=125113569524411&w=2
>>>>>
>>>>> Oops, my bad: I see now from the code that you did actually do #1,
>>>>> you
>>>>> just didn't mention it above.  OK!
>>>>>
>>>>> I don't see #2 or #3, though maybe they're already handled
>>>>> somewhere....
>>>>
>>>> No, not in the kernel's MNT client.  #3 seems like a server bug to
>>>> me,
>>>> though.
>>>
>>> Alas, it's apparently a workaround for a client bug: see the url
>>> referenced after #3.  (But I don't know what client versions that  
>>> bug
>>> was in.  If someone investigated and found they weren't widely
>>> distributed, I'd take a patch to remove the workaround.)
>>
>> How are clients supposed to tell if the server actually supports
>> AUTH_NULL but didn't list it, versus the admin specifically  
>> forbidding
>> the use of AUTH_NULL?
>
> They can't.  So the compromise I proposed was to avoid negotiating
> AUTH_NULL automatically, but to allow the user's explicit sec=null to
> override the server's returned list.  That said, I think I'm  
> convinced:
>
>> Mountd should list AUTH_NULL if the server admin specified it  
>> (although
>> it doesn't need to list AUTH_NULL by default).  The server is  
>> allowed to
>> reorder the flavor list, not the client, according to RFC 2623.  The
>> server's admin may even _prefer_ "rw,sec=null" access, in which case
>> listing AUTH_NULL first is actually desired.
>
> And in fact that's the way a recent linux server works.
>
> So if you do #2 above but not #3, then you can tell people: if you
> really need auth_null, you need to a) request it explicitly on the  
> mount
> commandline, b) upgrade to a recent mountd (at least 1.1.4), and c)  
> list
> it explicitly on the server export.
>
> And, sure, that'd be OK with me, and would probably be better than
> adding another exception, so I'm OK with skipping #3.  (We definitely
> shouldn't omit #2, though.)

Seems straightforward enough, but...  Why are we doing this again?  It  
still seems like non-standard behavior.  Are we simply attempting to  
avoid the case where folks would get the "nobody" behavior  
unexpectedly because of a mountd bug, or is there more to it?

I'm just thinking of what the documenting comment might say, and  
perhaps some explanation added to nfs(5).

>
> --b.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs"  
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: [PATCH] NFS: Change default behavior when "sec=" is not specified by user

[J. Bruce Fields]

On Tue, Sep 01, 2009 at 12:29:30PM -0400, Chuck Lever wrote:
> On Sep 1, 2009, at 12:09 PM, J. Bruce Fields wrote:
>> And, sure, that'd be OK with me, and would probably be better than
>> adding another exception, so I'm OK with skipping #3.  (We definitely
>> shouldn't omit #2, though.)
>
> Seems straightforward enough, but...  Why are we doing this again?  It  
> still seems like non-standard behavior.  Are we simply attempting to  
> avoid the case where folks would get the "nobody" behavior unexpectedly 
> because of a mountd bug, or is there more to it?

That's all there is to it.  As I said:

>>>>>> 	2. In the absence of sec=, we should probably *not* choose
>>>>>> 	AUTH_NULL.  (All mountd's before 1.1.3 list AUTH_NULL first on
>>>>>> 	the returned list, so users with older servers may wonder why a
>>>>>> 	client upgrade is making files they create suddenly be owned by
>>>>>> 	nobody.) http://marc.info/?l=linux-nfs&m=125089022306281&w=2

> I'm just thinking of what the documenting comment might say, and perhaps 
> some explanation added to nfs(5).

"As a special case, to work around bugs in some older servers, the
client will never automatically negotiate auth_null; if auth_null is
desired, an explicit "sec=null" on the commandline is required."

Or something like that.

--b.

Re: [PATCH] NFS: Change default behavior when "sec=" is not specified by user

[Chuck Lever]

On Sep 1, 2009, at 12:38 PM, J. Bruce Fields wrote:

> On Tue, Sep 01, 2009 at 12:29:30PM -0400, Chuck Lever wrote:
>> On Sep 1, 2009, at 12:09 PM, J. Bruce Fields wrote:
>>> And, sure, that'd be OK with me, and would probably be better than
>>> adding another exception, so I'm OK with skipping #3.  (We  
>>> definitely
>>> shouldn't omit #2, though.)
>>
>> Seems straightforward enough, but...  Why are we doing this again?   
>> It
>> still seems like non-standard behavior.  Are we simply attempting to
>> avoid the case where folks would get the "nobody" behavior  
>> unexpectedly
>> because of a mountd bug, or is there more to it?
>
> That's all there is to it.  As I said:
>
>>>>>>> 	2. In the absence of sec=, we should probably *not* choose
>>>>>>> 	AUTH_NULL.  (All mountd's before 1.1.3 list AUTH_NULL first on
>>>>>>> 	the returned list, so users with older servers may wonder why a
>>>>>>> 	client upgrade is making files they create suddenly be owned by
>>>>>>> 	nobody.) http://marc.info/?l=linux-nfs&m=125089022306281&w=2
>
>> I'm just thinking of what the documenting comment might say, and  
>> perhaps
>> some explanation added to nfs(5).
>
> "As a special case, to work around bugs in some older servers, the
> client will never automatically negotiate auth_null; if auth_null is
> desired, an explicit "sec=null" on the commandline is required."
>
> Or something like that.

OK, one more corner case.

What if the mount doesn't specify "sec=" and the only flavor in the  
server's auth list is AUTH_NULL?  Seems like we should allow that one.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: [PATCH] NFS: Change default behavior when "sec=" is not specified by user

[J. Bruce Fields]

On Tue, Sep 01, 2009 at 02:07:40PM -0400, Chuck Lever wrote:
>
> On Sep 1, 2009, at 12:38 PM, J. Bruce Fields wrote:
>
>> On Tue, Sep 01, 2009 at 12:29:30PM -0400, Chuck Lever wrote:
>>> On Sep 1, 2009, at 12:09 PM, J. Bruce Fields wrote:
>>>> And, sure, that'd be OK with me, and would probably be better than
>>>> adding another exception, so I'm OK with skipping #3.  (We  
>>>> definitely
>>>> shouldn't omit #2, though.)
>>>
>>> Seems straightforward enough, but...  Why are we doing this again?   
>>> It
>>> still seems like non-standard behavior.  Are we simply attempting to
>>> avoid the case where folks would get the "nobody" behavior  
>>> unexpectedly
>>> because of a mountd bug, or is there more to it?
>>
>> That's all there is to it.  As I said:
>>
>>>>>>>> 	2. In the absence of sec=, we should probably *not* choose
>>>>>>>> 	AUTH_NULL.  (All mountd's before 1.1.3 list AUTH_NULL first on
>>>>>>>> 	the returned list, so users with older servers may wonder why a
>>>>>>>> 	client upgrade is making files they create suddenly be owned by
>>>>>>>> 	nobody.) http://marc.info/?l=linux-nfs&m=125089022306281&w=2
>>
>>> I'm just thinking of what the documenting comment might say, and  
>>> perhaps
>>> some explanation added to nfs(5).
>>
>> "As a special case, to work around bugs in some older servers, the
>> client will never automatically negotiate auth_null; if auth_null is
>> desired, an explicit "sec=null" on the commandline is required."
>>
>> Or something like that.
>
> OK, one more corner case.
>
> What if the mount doesn't specify "sec=" and the only flavor in the  
> server's auth list is AUTH_NULL?  Seems like we should allow that one.

OK.--b.

Re: [PATCH] NFS: Change default behavior when "sec=" is not specified by user

[Trond Myklebust]

On Tue, 2009-09-01 at 14:07 -0400, Chuck Lever wrote:
> On Sep 1, 2009, at 12:38 PM, J. Bruce Fields wrote:
> 
> > On Tue, Sep 01, 2009 at 12:29:30PM -0400, Chuck Lever wrote:
> >> On Sep 1, 2009, at 12:09 PM, J. Bruce Fields wrote:
> >>> And, sure, that'd be OK with me, and would probably be better than
> >>> adding another exception, so I'm OK with skipping #3.  (We  
> >>> definitely
> >>> shouldn't omit #2, though.)
> >>
> >> Seems straightforward enough, but...  Why are we doing this again?   
> >> It
> >> still seems like non-standard behavior.  Are we simply attempting to
> >> avoid the case where folks would get the "nobody" behavior  
> >> unexpectedly
> >> because of a mountd bug, or is there more to it?
> >
> > That's all there is to it.  As I said:
> >
> >>>>>>> 	2. In the absence of sec=, we should probably *not* choose
> >>>>>>> 	AUTH_NULL.  (All mountd's before 1.1.3 list AUTH_NULL first on
> >>>>>>> 	the returned list, so users with older servers may wonder why a
> >>>>>>> 	client upgrade is making files they create suddenly be owned by
> >>>>>>> 	nobody.) http://marc.info/?l=linux-nfs&m=125089022306281&w=2
> >
> >> I'm just thinking of what the documenting comment might say, and  
> >> perhaps
> >> some explanation added to nfs(5).
> >
> > "As a special case, to work around bugs in some older servers, the
> > client will never automatically negotiate auth_null; if auth_null is
> > desired, an explicit "sec=null" on the commandline is required."
> >
> > Or something like that.
> 
> OK, one more corner case.
> 
> What if the mount doesn't specify "sec=" and the only flavor in the  
> server's auth list is AUTH_NULL?  Seems like we should allow that one.

Amend the above statement to "the only flavour in the server's auth list
that is supported by the client", and I'll agree.

If a server advertises auth_dh, auth_krb4 and auth_null, then we should
definitely try auth_null rather than failing.

Trond

Re: [PATCH] NFS: Change default behavior when "sec=" is not specified by user

[Trond Myklebust]

On Tue, 2009-09-01 at 14:25 -0400, Trond Myklebust wrote:
> On Tue, 2009-09-01 at 14:07 -0400, Chuck Lever wrote:
> > On Sep 1, 2009, at 12:38 PM, J. Bruce Fields wrote:
> > 
> > > On Tue, Sep 01, 2009 at 12:29:30PM -0400, Chuck Lever wrote:
> > >> On Sep 1, 2009, at 12:09 PM, J. Bruce Fields wrote:
> > >>> And, sure, that'd be OK with me, and would probably be better than
> > >>> adding another exception, so I'm OK with skipping #3.  (We  
> > >>> definitely
> > >>> shouldn't omit #2, though.)
> > >>
> > >> Seems straightforward enough, but...  Why are we doing this again?   
> > >> It
> > >> still seems like non-standard behavior.  Are we simply attempting to
> > >> avoid the case where folks would get the "nobody" behavior  
> > >> unexpectedly
> > >> because of a mountd bug, or is there more to it?
> > >
> > > That's all there is to it.  As I said:
> > >
> > >>>>>>> 	2. In the absence of sec=, we should probably *not* choose
> > >>>>>>> 	AUTH_NULL.  (All mountd's before 1.1.3 list AUTH_NULL first on
> > >>>>>>> 	the returned list, so users with older servers may wonder why a
> > >>>>>>> 	client upgrade is making files they create suddenly be owned by
> > >>>>>>> 	nobody.) http://marc.info/?l=linux-nfs&m=125089022306281&w=2
> > >
> > >> I'm just thinking of what the documenting comment might say, and  
> > >> perhaps
> > >> some explanation added to nfs(5).
> > >
> > > "As a special case, to work around bugs in some older servers, the
> > > client will never automatically negotiate auth_null; if auth_null is
> > > desired, an explicit "sec=null" on the commandline is required."
> > >
> > > Or something like that.
> > 
> > OK, one more corner case.
> > 
> > What if the mount doesn't specify "sec=" and the only flavor in the  
> > server's auth list is AUTH_NULL?  Seems like we should allow that one.
> 
> Amend the above statement to "the only flavour in the server's auth list
> that is supported by the client", and I'll agree.
> 
> If a server advertises auth_dh, auth_krb4 and auth_null, then we should
> definitely try auth_null rather than failing.

We should also try it if the server is broken, and returns an empty
list, but only after first attempting to cycle through all the other
flavours that are supported by the client.

Trond

Re: [PATCH] NFS: Change default behavior when "sec=" is not specified by user

[Trond Myklebust]

On Tue, 2009-09-01 at 14:28 -0400, Trond Myklebust wrote:
> We should also try it if the server is broken, and returns an empty
> list, but only after first attempting to cycle through all the other
> flavours that are supported by the client.

Note that this is also what we'll have to do in the case of NFSv4 minor
version 0, when trying to get round the problem of applying SECINFO to
the root directory.

NFSv4.1 doesn't have that problem, since you are always allowed to do
"PUTROOTFH; SECINFO_NO_NAME"...

Trond

Re: [PATCH] NFS: Change default behavior when "sec=" is not specified by user

[Chuck Lever]

On Sep 1, 2009, at 2:25 PM, Trond Myklebust wrote:
> On Tue, 2009-09-01 at 14:07 -0400, Chuck Lever wrote:
>> On Sep 1, 2009, at 12:38 PM, J. Bruce Fields wrote:
>>
>>> On Tue, Sep 01, 2009 at 12:29:30PM -0400, Chuck Lever wrote:
>>>> On Sep 1, 2009, at 12:09 PM, J. Bruce Fields wrote:
>>>>> And, sure, that'd be OK with me, and would probably be better than
>>>>> adding another exception, so I'm OK with skipping #3.  (We
>>>>> definitely
>>>>> shouldn't omit #2, though.)
>>>>
>>>> Seems straightforward enough, but...  Why are we doing this again?
>>>> It
>>>> still seems like non-standard behavior.  Are we simply attempting  
>>>> to
>>>> avoid the case where folks would get the "nobody" behavior
>>>> unexpectedly
>>>> because of a mountd bug, or is there more to it?
>>>
>>> That's all there is to it.  As I said:
>>>
>>>>>>>>> 	2. In the absence of sec=, we should probably *not* choose
>>>>>>>>> 	AUTH_NULL.  (All mountd's before 1.1.3 list AUTH_NULL first  
>>>>>>>>> on
>>>>>>>>> 	the returned list, so users with older servers may wonder  
>>>>>>>>> why a
>>>>>>>>> 	client upgrade is making files they create suddenly be  
>>>>>>>>> owned by
>>>>>>>>> 	nobody.) http://marc.info/?l=linux-nfs&m=125089022306281&w=2
>>>
>>>> I'm just thinking of what the documenting comment might say, and
>>>> perhaps
>>>> some explanation added to nfs(5).
>>>
>>> "As a special case, to work around bugs in some older servers, the
>>> client will never automatically negotiate auth_null; if auth_null is
>>> desired, an explicit "sec=null" on the commandline is required."
>>>
>>> Or something like that.
>>
>> OK, one more corner case.
>>
>> What if the mount doesn't specify "sec=" and the only flavor in the
>> server's auth list is AUTH_NULL?  Seems like we should allow that  
>> one.
>
> Amend the above statement to "the only flavour in the server's auth  
> list
> that is supported by the client", and I'll agree.

> If a server advertises auth_dh, auth_krb4 and auth_null, then we  
> should
> definitely try auth_null rather than failing.

What if the list has AUTH_GSS_KRB5 and AUTH_NULL?  Should the kernel  
try AUTH_GSS flavors if it can't tell whether gssd is running or there  
is a valid local keytab?

How does the kernel construct a list of client-supported auth flavors?

> We should also try it if the server is broken, and returns an empty
> list, but only after first attempting to cycle through all the other
> flavours that are supported by the client.


If the server returns an empty list, we can't negotiate.  We are  
fairly certain only old Linux servers return an empty list, in which  
case the client can assume all we've got is AUTH_NULL and AUTH_UNIX.   
I think allowing the mount to proceed with AUTH_UNIX is the best  
choice here.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: [PATCH] NFS: Change default behavior when "sec=" is not specified by user

[Trond Myklebust]

On Tue, 2009-09-01 at 14:58 -0400, Chuck Lever wrote:
> On Sep 1, 2009, at 2:25 PM, Trond Myklebust wrote:
> > On Tue, 2009-09-01 at 14:07 -0400, Chuck Lever wrote:
> >> OK, one more corner case.
> >>
> >> What if the mount doesn't specify "sec=" and the only flavor in the
> >> server's auth list is AUTH_NULL?  Seems like we should allow that  
> >> one.
> >
> > Amend the above statement to "the only flavour in the server's auth  
> > list
> > that is supported by the client", and I'll agree.
> 
> > If a server advertises auth_dh, auth_krb4 and auth_null, then we  
> > should
> > definitely try auth_null rather than failing.
> 
> What if the list has AUTH_GSS_KRB5 and AUTH_NULL?  Should the kernel  
> try AUTH_GSS flavors if it can't tell whether gssd is running or there  
> is a valid local keytab?

Firstly, we can tell if gssd is running. There is a timeout period of 30
seconds, but after that timeout, if there are no listeners on the end of
the gssd pipe, the rpc_pipefs code will return ETIMEDOUT.

> How does the kernel construct a list of client-supported auth flavors?

Although we do have the auth_flavors[] list, we don't currently have a
list that enumerates all the supported pseudoflavours. Instead, we have
auth_flavors[], and then a separate list of all the rpcsec_gss auth
mechanisms that are currently loaded into kernel memory.
I suggest we need to unify the information in those two lists, perhaps
by having everyone register into a separate list of all pseudoflavours
that are acceptable as parameters for rpcauth_create().

> > We should also try it if the server is broken, and returns an empty
> > list, but only after first attempting to cycle through all the other
> > flavours that are supported by the client.
> 
> 
> If the server returns an empty list, we can't negotiate.  We are  
> fairly certain only old Linux servers return an empty list, in which  
> case the client can assume all we've got is AUTH_NULL and AUTH_UNIX.   

...or RPCSEC_GSS/krb5

> I think allowing the mount to proceed with AUTH_UNIX is the best  
> choice here.

As I said, this functionality is in also required in order to make NFSv4
security negotiation work.

Trond

Re: [PATCH] NFS: Change default behavior when "sec=" is not specified by user

[Trond Myklebust]

On Tue, 2009-09-01 at 15:31 -0400, Trond Myklebust wrote:
> On Tue, 2009-09-01 at 14:58 -0400, Chuck Lever wrote:
> > On Sep 1, 2009, at 2:25 PM, Trond Myklebust wrote:
> > > On Tue, 2009-09-01 at 14:07 -0400, Chuck Lever wrote:
> > >> OK, one more corner case.
> > >>
> > >> What if the mount doesn't specify "sec=" and the only flavor in the
> > >> server's auth list is AUTH_NULL?  Seems like we should allow that  
> > >> one.
> > >
> > > Amend the above statement to "the only flavour in the server's auth  
> > > list
> > > that is supported by the client", and I'll agree.
> > 
> > > If a server advertises auth_dh, auth_krb4 and auth_null, then we  
> > > should
> > > definitely try auth_null rather than failing.
> > 
> > What if the list has AUTH_GSS_KRB5 and AUTH_NULL?  Should the kernel  
> > try AUTH_GSS flavors if it can't tell whether gssd is running or there  
> > is a valid local keytab?
> 
> Firstly, we can tell if gssd is running. There is a timeout period of 30
> seconds, but after that timeout, if there are no listeners on the end of
> the gssd pipe, the rpc_pipefs code will return ETIMEDOUT.
> 
> > How does the kernel construct a list of client-supported auth flavors?
> 
> Although we do have the auth_flavors[] list, we don't currently have a
> list that enumerates all the supported pseudoflavours. Instead, we have
> auth_flavors[], and then a separate list of all the rpcsec_gss auth
> mechanisms that are currently loaded into kernel memory.
> I suggest we need to unify the information in those two lists, perhaps
> by having everyone register into a separate list of all pseudoflavours
> that are acceptable as parameters for rpcauth_create().
> 
> > > We should also try it if the server is broken, and returns an empty
> > > list, but only after first attempting to cycle through all the other
> > > flavours that are supported by the client.
> > 
> > 
> > If the server returns an empty list, we can't negotiate.  We are  
> > fairly certain only old Linux servers return an empty list, in which  
> > case the client can assume all we've got is AUTH_NULL and AUTH_UNIX.   
> 
> ...or RPCSEC_GSS/krb5
> 
> > I think allowing the mount to proceed with AUTH_UNIX is the best  
> > choice here.
> 
> As I said, this functionality is in also required in order to make NFSv4
> security negotiation work.

...and for NFSv2 as well...

Trond

Re: [PATCH] NFS: Change default behavior when "sec=" is not specified by user

[Chuck Lever]

On Sep 1, 2009, at 3:31 PM, Trond Myklebust wrote:
> On Tue, 2009-09-01 at 14:58 -0400, Chuck Lever wrote:
>> On Sep 1, 2009, at 2:25 PM, Trond Myklebust wrote:
>>> On Tue, 2009-09-01 at 14:07 -0400, Chuck Lever wrote:
>>>> OK, one more corner case.
>>>>
>>>> What if the mount doesn't specify "sec=" and the only flavor in the
>>>> server's auth list is AUTH_NULL?  Seems like we should allow that
>>>> one.
>>>
>>> Amend the above statement to "the only flavour in the server's auth
>>> list
>>> that is supported by the client", and I'll agree.
>>
>>> If a server advertises auth_dh, auth_krb4 and auth_null, then we
>>> should
>>> definitely try auth_null rather than failing.
>>
>> What if the list has AUTH_GSS_KRB5 and AUTH_NULL?  Should the kernel
>> try AUTH_GSS flavors if it can't tell whether gssd is running or  
>> there
>> is a valid local keytab?
>
> Firstly, we can tell if gssd is running. There is a timeout period  
> of 30
> seconds, but after that timeout, if there are no listeners on the  
> end of
> the gssd pipe, the rpc_pipefs code will return ETIMEDOUT.

Oh, good!  Another 30 second timeout during mount!  :-)

But there's still no way to assess the validity or contents of the  
client's keytab.

>> How does the kernel construct a list of client-supported auth  
>> flavors?
>
> Although we do have the auth_flavors[] list, we don't currently have a
> list that enumerates all the supported pseudoflavours. Instead, we  
> have
> auth_flavors[], and then a separate list of all the rpcsec_gss auth
> mechanisms that are currently loaded into kernel memory.
> I suggest we need to unify the information in those two lists, perhaps
> by having everyone register into a separate list of all pseudoflavours
> that are acceptable as parameters for rpcauth_create().

OK, but that seems like more than we should try to do before 2.6.32.

>>> We should also try it if the server is broken, and returns an empty
>>> list, but only after first attempting to cycle through all the other
>>> flavours that are supported by the client.
>>
>>
>> If the server returns an empty list, we can't negotiate.  We are
>> fairly certain only old Linux servers return an empty list, in which
>> case the client can assume all we've got is AUTH_NULL and AUTH_UNIX.
>
> ...or RPCSEC_GSS/krb5

The server supports AUTH_GSS but doesn't return a flavor list?  I  
would like some confirmation that this behavior actually exists in the  
field.

>> I think allowing the mount to proceed with AUTH_UNIX is the best
>> choice here.
>
> As I said, this functionality is in also required in order to make  
> NFSv4
> security negotiation work.

This is all added to the kernel's MNT client.  None of this logic will  
ever be used by NFSv4, unless we refactor it someday.  At which time,  
we can worry about it then.

> ...and for NFSv2 as well...

Now you've lost me.  The v1 MNTPROC doesn't return a flavor list, so  
NFSv2 doesn't support security flavor negotiation at mount time.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: [PATCH] NFS: Change default behavior when "sec=" is not specified by user

[J. Bruce Fields]

On Tue, Sep 01, 2009 at 04:10:57PM -0400, Chuck Lever wrote:
> On Sep 1, 2009, at 3:31 PM, Trond Myklebust wrote:
>> As I said, this functionality is in also required in order to make  
>> NFSv4
>> security negotiation work.
>
> This is all added to the kernel's MNT client.  None of this logic will  
> ever be used by NFSv4, unless we refactor it someday.  At which time, we 
> can worry about it then.
>
>> ...and for NFSv2 as well...
>
> Now you've lost me.  The v1 MNTPROC doesn't return a flavor list, so  
> NFSv2 doesn't support security flavor negotiation at mount time.

The protocol doesn't have explicit support for it, just as NFSv4.0
doesn't in the case of security on /, but we can still support a form of
"negotiation" in both cases by doing a linear search through the
supported flavors and trying each one.

I agree that we should do that.  I don't think it necessarily needs to
be done *before* any of the other changes that have been discussed, so
it could be done as a second step.

--b.

Re: [PATCH] NFS: Change default behavior when "sec=" is not specified by user

[Chuck Lever]

On Sep 1, 2009, at 4:15 PM, J. Bruce Fields wrote:
> On Tue, Sep 01, 2009 at 04:10:57PM -0400, Chuck Lever wrote:
>> On Sep 1, 2009, at 3:31 PM, Trond Myklebust wrote:
>>> As I said, this functionality is in also required in order to make
>>> NFSv4
>>> security negotiation work.
>>
>> This is all added to the kernel's MNT client.  None of this logic  
>> will
>> ever be used by NFSv4, unless we refactor it someday.  At which  
>> time, we
>> can worry about it then.
>>
>>> ...and for NFSv2 as well...
>>
>> Now you've lost me.  The v1 MNTPROC doesn't return a flavor list, so
>> NFSv2 doesn't support security flavor negotiation at mount time.
>
> The protocol doesn't have explicit support for it, just as NFSv4.0
> doesn't in the case of security on /, but we can still support a  
> form of
> "negotiation" in both cases by doing a linear search through the
> supported flavors and trying each one.
>
> I agree that we should do that.  I don't think it necessarily needs to
> be done *before* any of the other changes that have been discussed, so
> it could be done as a second step.

For v4, you have WRONGSEC, but I don't think NFSv2 makes that  
distinction.  Would the client probe the server with NFS requests each  
using a different flavor?  Would we expect to see the RPC level "weak  
authentication" reply in the NFSv2 case?  Before Eisler says it, why  
would we bother?

Even so, that's a much different proposition than simply reading the  
flavor list returned by MNT3PROC, so I'm straining to see how we could  
reuse the logic I'm adding to the kernel's MNT client to do security  
negotiation for NFSv2.  If Trond is referring only to merging the  
kernel's auth flavor lists, then that comment makes more sense.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: [PATCH] NFS: Change default behavior when "sec=" is not specified by user

[Trond Myklebust]

On Tue, 2009-09-01 at 16:31 -0400, Chuck Lever wrote:
> For v4, you have WRONGSEC, but I don't think NFSv2 makes that  
> distinction.  Would the client probe the server with NFS requests each  
> using a different flavor?  Would we expect to see the RPC level "weak  
> authentication" reply in the NFSv2 case?  Before Eisler says it, why  
> would we bother?
> 
> Even so, that's a much different proposition than simply reading the  
> flavor list returned by MNT3PROC, so I'm straining to see how we could  
> reuse the logic I'm adding to the kernel's MNT client to do security  
> negotiation for NFSv2.  If Trond is referring only to merging the  
> kernel's auth flavor lists, then that comment makes more sense.

IMO the goal should be to have _one_ engine that can iterate through a
list of auth flavours (either the list provided by the MNT server, or
the list of all flavours supported by the client) until it gets a
positive response to an RPC call. We shouldn't assume that the flavour
that was negotiated at mount time is final.
It makes sense to code this iteration process at the RPC level instead
of at the NFS level. That enables us to use the same engine for NFSv2,
NFSv4, and the NFSv4.0 server (when doing client callbacks). Possibly
also for NLM and MOUNT (apparently IRIX used to support this)...

Re: [PATCH] NFS: Change default behavior when "sec=" is not specified by user

[Chuck Lever]

On Sep 1, 2009, at 5:22 PM, Trond Myklebust wrote:
> On Tue, 2009-09-01 at 16:31 -0400, Chuck Lever wrote:
>> For v4, you have WRONGSEC, but I don't think NFSv2 makes that
>> distinction.  Would the client probe the server with NFS requests  
>> each
>> using a different flavor?  Would we expect to see the RPC level "weak
>> authentication" reply in the NFSv2 case?  Before Eisler says it, why
>> would we bother?
>>
>> Even so, that's a much different proposition than simply reading the
>> flavor list returned by MNT3PROC, so I'm straining to see how we  
>> could
>> reuse the logic I'm adding to the kernel's MNT client to do security
>> negotiation for NFSv2.  If Trond is referring only to merging the
>> kernel's auth flavor lists, then that comment makes more sense.
>
> IMO the goal should be to have _one_ engine that can iterate through a
> list of auth flavours (either the list provided by the MNT server, or
> the list of all flavours supported by the client) until it gets a
> positive response to an RPC call.

OK, but that's not what the MNT client has to do with the list  
returned from MNT3PROC.  All it needs to do is check the requested  
auth flavor against the returned list, or pick the first supported  
flavor on the list if the user didn't request one.

So my practical question still remains.  For 2.6.32, how should the  
kernel's MNT client determine the list of supported authentication  
flavors?  (I understand that one answer might be "we can't do an  
adequate job of that at this point, so we probably should drop MNT  
authlist support until we can").

> We shouldn't assume that the flavour
> that was negotiated at mount time is final.

Why not?  That's how NFSv2 and NFSv3 have worked forever.  And, how  
will client admins enforce the use of a particular security flavor if  
they can't be sure that the client won't renegotiate it?

For NFSv3, you can save the list of supported flavors returned by  
MNT3PROC on the client to do renegotiation later, but what happens  
when the server admin changes the auth flavors for an export that the  
client has already mounted?

> It makes sense to code this iteration process at the RPC level instead
> of at the NFS level. That enables us to use the same engine for NFSv2,
> NFSv4, and the NFSv4.0 server (when doing client callbacks). Possibly
> also for NLM and MOUNT (apparently IRIX used to support this)...

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: [PATCH] NFS: Change default behavior when "sec=" is not specified by user

[Peter Staubach]

Chuck Lever wrote:
> 
> On Sep 1, 2009, at 12:38 PM, J. Bruce Fields wrote:
> 
>> On Tue, Sep 01, 2009 at 12:29:30PM -0400, Chuck Lever wrote:
>>> On Sep 1, 2009, at 12:09 PM, J. Bruce Fields wrote:
>>>> And, sure, that'd be OK with me, and would probably be better than
>>>> adding another exception, so I'm OK with skipping #3.  (We definitely
>>>> shouldn't omit #2, though.)
>>>
>>> Seems straightforward enough, but...  Why are we doing this again?  It
>>> still seems like non-standard behavior.  Are we simply attempting to
>>> avoid the case where folks would get the "nobody" behavior unexpectedly
>>> because of a mountd bug, or is there more to it?
>>
>> That's all there is to it.  As I said:
>>
>>>>>>>>     2. In the absence of sec=, we should probably *not* choose
>>>>>>>>     AUTH_NULL.  (All mountd's before 1.1.3 list AUTH_NULL first on
>>>>>>>>     the returned list, so users with older servers may wonder why a
>>>>>>>>     client upgrade is making files they create suddenly be owned by
>>>>>>>>     nobody.) http://marc.info/?l=linux-nfs&m=125089022306281&w=2
>>
>>> I'm just thinking of what the documenting comment might say, and perhaps
>>> some explanation added to nfs(5).
>>
>> "As a special case, to work around bugs in some older servers, the
>> client will never automatically negotiate auth_null; if auth_null is
>> desired, an explicit "sec=null" on the commandline is required."
>>
>> Or something like that.
> 
> OK, one more corner case.
> 
> What if the mount doesn't specify "sec=" and the only flavor in the
> server's auth list is AUTH_NULL?  Seems like we should allow that one.
> 

Some servers will accept any flavor of incoming RPC security
and just use AUTH_NULL in this situation.  It really shouldn't
matter what the client sends, as long as the server is just
going to map all requests to nobody/nobody anyway...

		ps

Re: [PATCH] NFS: Change default behavior when "sec=" is not specified by user

[J. Bruce Fields]

On Tue, Sep 01, 2009 at 02:33:50PM -0400, Peter Staubach wrote:
> Chuck Lever wrote:
> > 
> > On Sep 1, 2009, at 12:38 PM, J. Bruce Fields wrote:
> > 
> >> On Tue, Sep 01, 2009 at 12:29:30PM -0400, Chuck Lever wrote:
> >>> On Sep 1, 2009, at 12:09 PM, J. Bruce Fields wrote:
> >>>> And, sure, that'd be OK with me, and would probably be better than
> >>>> adding another exception, so I'm OK with skipping #3.  (We definitely
> >>>> shouldn't omit #2, though.)
> >>>
> >>> Seems straightforward enough, but...  Why are we doing this again?  It
> >>> still seems like non-standard behavior.  Are we simply attempting to
> >>> avoid the case where folks would get the "nobody" behavior unexpectedly
> >>> because of a mountd bug, or is there more to it?
> >>
> >> That's all there is to it.  As I said:
> >>
> >>>>>>>>     2. In the absence of sec=, we should probably *not* choose
> >>>>>>>>     AUTH_NULL.  (All mountd's before 1.1.3 list AUTH_NULL first on
> >>>>>>>>     the returned list, so users with older servers may wonder why a
> >>>>>>>>     client upgrade is making files they create suddenly be owned by
> >>>>>>>>     nobody.) http://marc.info/?l=linux-nfs&m=125089022306281&w=2
> >>
> >>> I'm just thinking of what the documenting comment might say, and perhaps
> >>> some explanation added to nfs(5).
> >>
> >> "As a special case, to work around bugs in some older servers, the
> >> client will never automatically negotiate auth_null; if auth_null is
> >> desired, an explicit "sec=null" on the commandline is required."
> >>
> >> Or something like that.
> > 
> > OK, one more corner case.
> > 
> > What if the mount doesn't specify "sec=" and the only flavor in the
> > server's auth list is AUTH_NULL?  Seems like we should allow that one.
> > 
> 
> Some servers will accept any flavor of incoming RPC security
> and just use AUTH_NULL in this situation.  It really shouldn't
> matter what the client sends, as long as the server is just
> going to map all requests to nobody/nobody anyway...

OK, but let's not pile on more workarounds than we have to.  I don't see
any reason that we really need to do anything special for servers that
are broken in *that* particular way....

--b.

Re: [PATCH] NFS: Change default behavior when "sec=" is not specified by user

[Peter Staubach]

J. Bruce Fields wrote:
> On Tue, Sep 01, 2009 at 02:33:50PM -0400, Peter Staubach wrote:
>> Chuck Lever wrote:
>>> On Sep 1, 2009, at 12:38 PM, J. Bruce Fields wrote:
>>>
>>>> On Tue, Sep 01, 2009 at 12:29:30PM -0400, Chuck Lever wrote:
>>>>> On Sep 1, 2009, at 12:09 PM, J. Bruce Fields wrote:
>>>>>> And, sure, that'd be OK with me, and would probably be better than
>>>>>> adding another exception, so I'm OK with skipping #3.  (We definitely
>>>>>> shouldn't omit #2, though.)
>>>>> Seems straightforward enough, but...  Why are we doing this again?  It
>>>>> still seems like non-standard behavior.  Are we simply attempting to
>>>>> avoid the case where folks would get the "nobody" behavior unexpectedly
>>>>> because of a mountd bug, or is there more to it?
>>>> That's all there is to it.  As I said:
>>>>
>>>>>>>>>>     2. In the absence of sec=, we should probably *not* choose
>>>>>>>>>>     AUTH_NULL.  (All mountd's before 1.1.3 list AUTH_NULL first on
>>>>>>>>>>     the returned list, so users with older servers may wonder why a
>>>>>>>>>>     client upgrade is making files they create suddenly be owned by
>>>>>>>>>>     nobody.) http://marc.info/?l=linux-nfs&m=125089022306281&w=2
>>>>> I'm just thinking of what the documenting comment might say, and perhaps
>>>>> some explanation added to nfs(5).
>>>> "As a special case, to work around bugs in some older servers, the
>>>> client will never automatically negotiate auth_null; if auth_null is
>>>> desired, an explicit "sec=null" on the commandline is required."
>>>>
>>>> Or something like that.
>>> OK, one more corner case.
>>>
>>> What if the mount doesn't specify "sec=" and the only flavor in the
>>> server's auth list is AUTH_NULL?  Seems like we should allow that one.
>>>
>> Some servers will accept any flavor of incoming RPC security
>> and just use AUTH_NULL in this situation.  It really shouldn't
>> matter what the client sends, as long as the server is just
>> going to map all requests to nobody/nobody anyway...
> 
> OK, but let's not pile on more workarounds than we have to.  I don't see
> any reason that we really need to do anything special for servers that
> are broken in *that* particular way....
> 

I don't think that that is considered to be broken, by the way.

I am not sure whether it still works this way, but I know that
Solaris used to work this way, at the very least.

Since I clearly haven't looked, but why would the Linux NFS
server care which flavor that it got sent, if the export is
configured to map all requests to nobody/nobody?

		ps

Re: [PATCH] NFS: Change default behavior when "sec=" is not specified by user

[J. Bruce Fields]

On Tue, Sep 01, 2009 at 02:52:44PM -0400, Peter Staubach wrote:
> J. Bruce Fields wrote:
> > On Tue, Sep 01, 2009 at 02:33:50PM -0400, Peter Staubach wrote:
> >> Some servers will accept any flavor of incoming RPC security
> >> and just use AUTH_NULL in this situation.  It really shouldn't
> >> matter what the client sends, as long as the server is just
> >> going to map all requests to nobody/nobody anyway...
> > 
> > OK, but let's not pile on more workarounds than we have to.  I don't see
> > any reason that we really need to do anything special for servers that
> > are broken in *that* particular way....
> > 
> 
> I don't think that that is considered to be broken, by the way.

OK, maybe not.

> I am not sure whether it still works this way, but I know that
> Solaris used to work this way, at the very least.
> 
> Since I clearly haven't looked, but why would the Linux NFS
> server care which flavor that it got sent, if the export is
> configured to map all requests to nobody/nobody?

I can think of any number of reasons, but on the client side I don't see
any great advantage to taking "auth_null" to mean "use anything you
want": it's another special case, it's undocumented and will only work
on some servers, and if it's really what the administrator wants, it
should be easy to fix the server to advertise everything while still
doing the id-squashing.

--b.

Re: [PATCH] NFS: Change default behavior when "sec=" is not specified by user

[Peter Staubach]

J. Bruce Fields wrote:
> On Tue, Sep 01, 2009 at 02:52:44PM -0400, Peter Staubach wrote:
>> J. Bruce Fields wrote:
>>> On Tue, Sep 01, 2009 at 02:33:50PM -0400, Peter Staubach wrote:
>>>> Some servers will accept any flavor of incoming RPC security
>>>> and just use AUTH_NULL in this situation.  It really shouldn't
>>>> matter what the client sends, as long as the server is just
>>>> going to map all requests to nobody/nobody anyway...
>>> OK, but let's not pile on more workarounds than we have to.  I don't see
>>> any reason that we really need to do anything special for servers that
>>> are broken in *that* particular way....
>>>
>> I don't think that that is considered to be broken, by the way.
> 
> OK, maybe not.
> 
>> I am not sure whether it still works this way, but I know that
>> Solaris used to work this way, at the very least.
>>
>> Since I clearly haven't looked, but why would the Linux NFS
>> server care which flavor that it got sent, if the export is
>> configured to map all requests to nobody/nobody?
> 
> I can think of any number of reasons, but on the client side I don't see
> any great advantage to taking "auth_null" to mean "use anything you
> want": it's another special case, it's undocumented and will only work
> on some servers, and if it's really what the administrator wants, it
> should be easy to fix the server to advertise everything while still
> doing the id-squashing.
> 

I don't understand this last.  Why would the server bother to
advertise the various flavors if they are all going to treated
as if they were AUTH_NONE?  It would seem to violate expectations
that clients may have, that they issued authentic and verifiable
requests, only to be treated as if they were not?

Just out of curiosity, any number of reasons?  :-)

This all seems like a lot of conversation and work just to try
to figure out how to accommodate a configuration which has
already indicated that it will ignore any incoming authentication
information.  I would suggest that we take the easy and obvious
way of sending AUTH_UNIX to such systems and if we find one that
really insists upon receiving AUTH_NONE from the client, then
we fix the client.  Many clients can't even generate AUTH_NONE,
by the way...

		ps

		ps

Re: [PATCH] NFS: Change default behavior when "sec=" is not specified by user

[J. Bruce Fields]

On Tue, Sep 01, 2009 at 03:24:06PM -0400, Peter Staubach wrote:
> J. Bruce Fields wrote:
> > On Tue, Sep 01, 2009 at 02:52:44PM -0400, Peter Staubach wrote:
> >> J. Bruce Fields wrote:
> >>> On Tue, Sep 01, 2009 at 02:33:50PM -0400, Peter Staubach wrote:
> >>>> Some servers will accept any flavor of incoming RPC security
> >>>> and just use AUTH_NULL in this situation.  It really shouldn't
> >>>> matter what the client sends, as long as the server is just
> >>>> going to map all requests to nobody/nobody anyway...
> >>> OK, but let's not pile on more workarounds than we have to.  I don't see
> >>> any reason that we really need to do anything special for servers that
> >>> are broken in *that* particular way....
> >>>
> >> I don't think that that is considered to be broken, by the way.
> > 
> > OK, maybe not.
> > 
> >> I am not sure whether it still works this way, but I know that
> >> Solaris used to work this way, at the very least.
> >>
> >> Since I clearly haven't looked, but why would the Linux NFS
> >> server care which flavor that it got sent, if the export is
> >> configured to map all requests to nobody/nobody?
> > 
> > I can think of any number of reasons, but on the client side I don't see
> > any great advantage to taking "auth_null" to mean "use anything you
> > want": it's another special case, it's undocumented and will only work
> > on some servers, and if it's really what the administrator wants, it
> > should be easy to fix the server to advertise everything while still
> > doing the id-squashing.
> > 
> 
> I don't understand this last.  Why would the server bother to
> advertise the various flavors if they are all going to treated
> as if they were AUTH_NONE?

There's a huge difference between the security characteristics of
AUTH_NONE and AUTH_GSS, even when the latter is id-squashed.

The security flavor list is meant to advertise acceptable security
flavors, not the server's id-mapping configuration.

(But I might understand the more limited case of treating auth_none and
auth_sys the same.)

> It would seem to violate expectations
> that clients may have, that they issued authentic and verifiable
> requests, only to be treated as if they were not?
> 
> Just out of curiosity, any number of reasons?  :-)

The server might simply not have support for AUTH_GSS: krb5 might not be
completely set up, or whatever, in which case it's simpler to refuse
those security flavors right away rather than to, say, risk waiting for
a timeout somewhere.

Or maybe the krb5 negotiation imposes undesireable load somewhere.

> This all seems like a lot of conversation and work just to try
> to figure out how to accommodate a configuration which has
> already indicated that it will ignore any incoming authentication
> information.  I would suggest that we take the easy and obvious
> way of sending AUTH_UNIX to such systems and if we find one that
> really insists upon receiving AUTH_NONE from the client, then
> we fix the client.

I believe a recent linux server, at least, will only accept auth_none if
that's all it advertises.  That behavior seemed, well, easy and obvious.

We could change it to treat auth_none and auth_sys interchangeably.  But
there'd still be servers out there with that behavior.  And I don't see
any advantage to the client to using auth_sys in this particular case.

--b.