I want to understand the server bug a little more. I glanced over RFC
2623 and didn't see anything specific.
Is it the case that only Linux NFSD does this, or do other servers do
it? In other words, is this a typical server response, and if so, is
there a specific semantic attached to it?
If no list is provided, should the client assume that only AUTH_NONE
and AUTH_SYS are supported, or instead, perhaps that the client can
try to use any flavor? In other words, if no list is provided, let
the mount proceed no matter what was specified by sec= ?
Thanks for any clarification.
Begin forwarded message:
> From: Trond Myklebust <[email protected]>
> Date: August 20, 2009 10:36:11 PM GMT-04:00
> To: Wu Fengguang <[email protected]>, "Mr. Charles Edward
> Lever" <[email protected]>
> Cc: "[email protected]" <[email protected]>, LKML <[email protected]
> >
> Subject: Re: mount.nfs: access denied by server
>
> On Fri, 2009-08-21 at 09:27 +0800, Wu Fengguang wrote:
>> On Thu, Aug 20, 2009 at 09:02:29PM +0800, Trond Myklebust wrote:
>>> On Thu, 2009-08-20 at 15:13 +0800, Wu Fengguang wrote:
>>>> Hi,
>>>>
>>>> After upgrading NFS client kernel to latest linux-next, NFS mount
>>>> failed:
>>>>
>>>> # mount -t nfs pxe:/cc /cc
>>>> mount.nfs: access denied by server while mounting pxe:/cc
>>>>
>>>> # uname -a
>>>> Linux hp 2.6.31-rc6-next-20090818 #61 SMP Thu Aug 20
>>>> 14:46:10 CST 2009 x86_64 GNU/Linux
>>>>
>>>> However server log says OK:
>>>>
>>>> Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated mount
>>>> request from 192.168.11.6:973 for /cc (/cc)
>>>> Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated unmount
>>>> request from 192.168.11.6:974 for /cc (/cc)
>>>>
>>>> However-2: nfsroot can be mounted at boot time. Server kernel has
>>>> always been 2.6.30.
>>>>
>>>> Any ideas?
>>>>
>>>> Thanks,
>>>> Fengguang
>>>
>>> Can you try again after enabling mount debugging on the NFS client?
>>>
>>> echo 512 > /proc/sys/sunrpc/nfs_debug
>>
>> I used 1024 and found the mount failed here in nfs_walk_authlist():
>>
>> dfprintk(MOUNT, "NFS: server does not support requested auth
>> flavor\ n");
>> nfs_umount(request);
>
> Thanks Fengguang!
>
> Chuck, this looks like one of yours. Could it be that you are hitting
> the same Linux knfsd bug that Tom Haynes saw with a Solaris client?
> AFAICR, the problem was that existing nfs servers do not set a default
> auth flavour, and so you just have to try with auth_sys and see if it
> succeeds...
>
> Cheers
> Trond
>
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
On 08/21/2009 02:20 PM, J. Bruce Fields wrote:
> Author: J. Bruce Fields <[email protected]>
> Date: Tue Jul 21 19:30:04 2009 -0400
>
> Don't give client an empty flavor list
>
> In the absence of an explicit sec= option on an export, rpc.mountd is
> returning a zero-length flavor list to clients in the MOUNT results.
>
> The linux client doesn't seem to mind, but the Solaris client
> (reasonably enough) is giving up; the symptom is a "security mode does
> not match" error on mount.
>
> We could modify the export-parsing code to ensure the secinfo array is
> nonzero. But I think it's slightly simpler to handle this default case
> in the implementation of the MOUNT call. This is more-or-less the same
> thing the kernel does when mountd passes it an export without any
> security flavors specified.
>
> Thanks to Tom Haynes for bug report and diagnosis.
>
> Signed-off-by: J. Bruce Fields <[email protected]>
>
> diff --git a/utils/mountd/mountd.c b/utils/mountd/mountd.c
> index b59f939..888fd8c 100644
> --- a/utils/mountd/mountd.c
> +++ b/utils/mountd/mountd.c
> @@ -359,6 +359,11 @@ static void set_authflavors(struct mountres3_ok *ok, nfs_export *exp)
> flavors[i] = s->flav->fnum;
> i++;
> }
> + if (i == 0) {
> + /* default when there is no sec= option: */
> + i = 1;
> + flavors[0] = AUTH_UNIX;
> + }
> ok->auth_flavors.auth_flavors_val = flavors;
> ok->auth_flavors.auth_flavors_len = i;
> }
Committed....
steved.
On Fri, Aug 21, 2009 at 02:16:08PM -0400, Chuck Lever wrote:
> I want to understand the server bug a little more. I glanced over RFC
> 2623 and didn't see anything specific.
>
> Is it the case that only Linux NFSD does this, or do other servers do
> it? In other words, is this a typical server response, and if so, is
> there a specific semantic attached to it?
>
> If no list is provided, should the client assume that only AUTH_NONE and
> AUTH_SYS are supported, or instead, perhaps that the client can try to
> use any flavor? In other words, if no list is provided, let the mount
> proceed no matter what was specified by sec= ?
I've sent the following to Steve to fix the server bug.
--b.
commit ceb3c96d68f47cf6a0c38ccd88b98c59c886e9fb
Author: J. Bruce Fields <[email protected]>
Date: Tue Jul 21 19:30:04 2009 -0400
Don't give client an empty flavor list
In the absence of an explicit sec= option on an export, rpc.mountd is
returning a zero-length flavor list to clients in the MOUNT results.
The linux client doesn't seem to mind, but the Solaris client
(reasonably enough) is giving up; the symptom is a "security mode does
not match" error on mount.
We could modify the export-parsing code to ensure the secinfo array is
nonzero. But I think it's slightly simpler to handle this default case
in the implementation of the MOUNT call. This is more-or-less the same
thing the kernel does when mountd passes it an export without any
security flavors specified.
Thanks to Tom Haynes for bug report and diagnosis.
Signed-off-by: J. Bruce Fields <[email protected]>
diff --git a/utils/mountd/mountd.c b/utils/mountd/mountd.c
index b59f939..888fd8c 100644
--- a/utils/mountd/mountd.c
+++ b/utils/mountd/mountd.c
@@ -359,6 +359,11 @@ static void set_authflavors(struct mountres3_ok *ok, nfs_export *exp)
flavors[i] = s->flav->fnum;
i++;
}
+ if (i == 0) {
+ /* default when there is no sec= option: */
+ i = 1;
+ flavors[0] = AUTH_UNIX;
+ }
ok->auth_flavors.auth_flavors_val = flavors;
ok->auth_flavors.auth_flavors_len = i;
}
On Fri, Aug 21, 2009 at 02:16:08PM -0400, Chuck Lever wrote:
> I want to understand the server bug a little more. I glanced over RFC
> 2623 and didn't see anything specific.
>
> Is it the case that only Linux NFSD does this, or do other servers do
> it? In other words, is this a typical server response, and if so, is
> there a specific semantic attached to it?
>
> If no list is provided, should the client assume that only AUTH_NONE and
> AUTH_SYS are supported, or instead, perhaps that the client can try to
> use any flavor? In other words, if no list is provided, let the mount
> proceed no matter what was specified by sec= ?
I think the safest behavior on the client would be something like:
- If an explicit sec= is provided on the client, try that
flavor. Otherwise:
- If the server returned a nonempty list, pick something
off that list. Otherwise:
- Try auth_sys.
--b.
>
> Thanks for any clarification.
>
> Begin forwarded message:
>
>> From: Trond Myklebust <[email protected]>
>> Date: August 20, 2009 10:36:11 PM GMT-04:00
>> To: Wu Fengguang <[email protected]>, "Mr. Charles Edward Lever"
>> <[email protected]>
>> Cc: "[email protected]" <[email protected]>, LKML
>> <[email protected]>
>> Subject: Re: mount.nfs: access denied by server
>>
>> On Fri, 2009-08-21 at 09:27 +0800, Wu Fengguang wrote:
>>> On Thu, Aug 20, 2009 at 09:02:29PM +0800, Trond Myklebust wrote:
>>>> On Thu, 2009-08-20 at 15:13 +0800, Wu Fengguang wrote:
>>>>> Hi,
>>>>>
>>>>> After upgrading NFS client kernel to latest linux-next, NFS mount
>>>>> failed:
>>>>>
>>>>> # mount -t nfs pxe:/cc /cc
>>>>> mount.nfs: access denied by server while mounting pxe:/cc
>>>>>
>>>>> # uname -a
>>>>> Linux hp 2.6.31-rc6-next-20090818 #61 SMP Thu Aug 20
>>>>> 14:46:10 CST 2009 x86_64 GNU/Linux
>>>>>
>>>>> However server log says OK:
>>>>>
>>>>> Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated mount
>>>>> request from 192.168.11.6:973 for /cc (/cc)
>>>>> Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated unmount
>>>>> request from 192.168.11.6:974 for /cc (/cc)
>>>>>
>>>>> However-2: nfsroot can be mounted at boot time. Server kernel has
>>>>> always been 2.6.30.
>>>>>
>>>>> Any ideas?
>>>>>
>>>>> Thanks,
>>>>> Fengguang
>>>>
>>>> Can you try again after enabling mount debugging on the NFS client?
>>>>
>>>> echo 512 > /proc/sys/sunrpc/nfs_debug
>>>
>>> I used 1024 and found the mount failed here in nfs_walk_authlist():
>>>
>>> dfprintk(MOUNT, "NFS: server does not support requested auth
>>> flavor\ n");
>>> nfs_umount(request);
>>
>> Thanks Fengguang!
>>
>> Chuck, this looks like one of yours. Could it be that you are hitting
>> the same Linux knfsd bug that Tom Haynes saw with a Solaris client?
>> AFAICR, the problem was that existing nfs servers do not set a default
>> auth flavour, and so you just have to try with auth_sys and see if it
>> succeeds...
>>
>> Cheers
>> Trond
>>
>
> --
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
>
>
>
On Aug 21, 2009, at 2:24 PM, J. Bruce Fields wrote:
> On Fri, Aug 21, 2009 at 02:16:08PM -0400, Chuck Lever wrote:
>> I want to understand the server bug a little more. I glanced over
>> RFC
>> 2623 and didn't see anything specific.
>>
>> Is it the case that only Linux NFSD does this, or do other servers do
>> it? In other words, is this a typical server response, and if so, is
>> there a specific semantic attached to it?
>>
>> If no list is provided, should the client assume that only
>> AUTH_NONE and
>> AUTH_SYS are supported, or instead, perhaps that the client can try
>> to
>> use any flavor? In other words, if no list is provided, let the
>> mount
>> proceed no matter what was specified by sec= ?
>
> I think the safest behavior on the client would be something like:
>
> - If an explicit sec= is provided on the client, try that
> flavor. Otherwise:
> - If the server returned a nonempty list, pick something
> off that list. Otherwise:
> - Try auth_sys.
Right now, we use AUTH_SYS if the mount command didn't specify a
flavor, but the flavor we're going to use is always checked against
the server's returned list. You seem to be suggesting we should
ignore the server's list entirely if sec= was specified...?
>
> --b.
>
>>
>> Thanks for any clarification.
>>
>> Begin forwarded message:
>>
>>> From: Trond Myklebust <[email protected]>
>>> Date: August 20, 2009 10:36:11 PM GMT-04:00
>>> To: Wu Fengguang <[email protected]>, "Mr. Charles Edward
>>> Lever"
>>> <[email protected]>
>>> Cc: "[email protected]" <[email protected]>, LKML
>>> <[email protected]>
>>> Subject: Re: mount.nfs: access denied by server
>>>
>>> On Fri, 2009-08-21 at 09:27 +0800, Wu Fengguang wrote:
>>>> On Thu, Aug 20, 2009 at 09:02:29PM +0800, Trond Myklebust wrote:
>>>>> On Thu, 2009-08-20 at 15:13 +0800, Wu Fengguang wrote:
>>>>>> Hi,
>>>>>>
>>>>>> After upgrading NFS client kernel to latest linux-next, NFS mount
>>>>>> failed:
>>>>>>
>>>>>> # mount -t nfs pxe:/cc /cc
>>>>>> mount.nfs: access denied by server while mounting pxe:/cc
>>>>>>
>>>>>> # uname -a
>>>>>> Linux hp 2.6.31-rc6-next-20090818 #61 SMP Thu Aug 20
>>>>>> 14:46:10 CST 2009 x86_64 GNU/Linux
>>>>>>
>>>>>> However server log says OK:
>>>>>>
>>>>>> Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated mount
>>>>>> request from 192.168.11.6:973 for /cc (/cc)
>>>>>> Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated unmount
>>>>>> request from 192.168.11.6:974 for /cc (/cc)
>>>>>>
>>>>>> However-2: nfsroot can be mounted at boot time. Server kernel has
>>>>>> always been 2.6.30.
>>>>>>
>>>>>> Any ideas?
>>>>>>
>>>>>> Thanks,
>>>>>> Fengguang
>>>>>
>>>>> Can you try again after enabling mount debugging on the NFS
>>>>> client?
>>>>>
>>>>> echo 512 > /proc/sys/sunrpc/nfs_debug
>>>>
>>>> I used 1024 and found the mount failed here in nfs_walk_authlist():
>>>>
>>>> dfprintk(MOUNT, "NFS: server does not support requested auth
>>>> flavor\ n");
>>>> nfs_umount(request);
>>>
>>> Thanks Fengguang!
>>>
>>> Chuck, this looks like one of yours. Could it be that you are
>>> hitting
>>> the same Linux knfsd bug that Tom Haynes saw with a Solaris client?
>>> AFAICR, the problem was that existing nfs servers do not set a
>>> default
>>> auth flavour, and so you just have to try with auth_sys and see if
>>> it
>>> succeeds...
>>>
>>> Cheers
>>> Trond
>>>
>>
>> --
>> Chuck Lever
>> chuck[dot]lever[at]oracle[dot]com
>>
>>
>>
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
Sent from my iPhone
On Aug 21, 2009, at 1:24 PM, "J. Bruce Fields" <[email protected]>
wrote:
> On Fri, Aug 21, 2009 at 02:16:08PM -0400, Chuck Lever wrote:
>> I want to understand the server bug a little more. I glanced over
>> RFC
>> 2623 and didn't see anything specific.
>>
>> Is it the case that only Linux NFSD does this, or do other servers do
>> it? In other words, is this a typical server response, and if so, is
>> there a specific semantic attached to it?
>>
>> If no list is provided, should the client assume that only
>> AUTH_NONE and
>> AUTH_SYS are supported, or instead, perhaps that the client can try
>> to
>> use any flavor? In other words, if no list is provided, let the
>> mount
>> proceed no matter what was specified by sec= ?
>
> I think the safest behavior on the client would be something like:
>
> - If an explicit sec= is provided on the client, try that
> flavor. Otherwise:
> - If the server returned a nonempty list, pick something
> off that list. Otherwise:
> - Try auth_sys.
>
Which is pretty much what we do. The exception being that the default
flavor is a setting - and probably always AUTH_SYS...
> --b.
>
>>
>> Thanks for any clarification.
>>
>> Begin forwarded message:
>>
>>> From: Trond Myklebust <[email protected]>
>>> Date: August 20, 2009 10:36:11 PM GMT-04:00
>>> To: Wu Fengguang <[email protected]>, "Mr. Charles Edward
>>> Lever"
>>> <[email protected]>
>>> Cc: "[email protected]" <[email protected]>, LKML
>>> <[email protected]>
>>> Subject: Re: mount.nfs: access denied by server
>>>
>>> On Fri, 2009-08-21 at 09:27 +0800, Wu Fengguang wrote:
>>>> On Thu, Aug 20, 2009 at 09:02:29PM +0800, Trond Myklebust wrote:
>>>>> On Thu, 2009-08-20 at 15:13 +0800, Wu Fengguang wrote:
>>>>>> Hi,
>>>>>>
>>>>>> After upgrading NFS client kernel to latest linux-next, NFS mount
>>>>>> failed:
>>>>>>
>>>>>> # mount -t nfs pxe:/cc /cc
>>>>>> mount.nfs: access denied by server while mounting pxe:/cc
>>>>>>
>>>>>> # uname -a
>>>>>> Linux hp 2.6.31-rc6-next-20090818 #61 SMP Thu Aug 20
>>>>>> 14:46:10 CST 2009 x86_64 GNU/Linux
>>>>>>
>>>>>> However server log says OK:
>>>>>>
>>>>>> Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated mount
>>>>>> request from 192.168.11.6:973 for /cc (/cc)
>>>>>> Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated unmount
>>>>>> request from 192.168.11.6:974 for /cc (/cc)
>>>>>>
>>>>>> However-2: nfsroot can be mounted at boot time. Server kernel has
>>>>>> always been 2.6.30.
>>>>>>
>>>>>> Any ideas?
>>>>>>
>>>>>> Thanks,
>>>>>> Fengguang
>>>>>
>>>>> Can you try again after enabling mount debugging on the NFS
>>>>> client?
>>>>>
>>>>> echo 512 > /proc/sys/sunrpc/nfs_debug
>>>>
>>>> I used 1024 and found the mount failed here in nfs_walk_authlist():
>>>>
>>>> dfprintk(MOUNT, "NFS: server does not support requested auth
>>>> flavor\ n");
>>>> nfs_umount(request);
>>>
>>> Thanks Fengguang!
>>>
>>> Chuck, this looks like one of yours. Could it be that you are
>>> hitting
>>> the same Linux knfsd bug that Tom Haynes saw with a Solaris client?
>>> AFAICR, the problem was that existing nfs servers do not set a
>>> default
>>> auth flavour, and so you just have to try with auth_sys and see if
>>> it
>>> succeeds...
>>>
>>> Cheers
>>> Trond
>>>
>>
>> --
>> Chuck Lever
>> chuck[dot]lever[at]oracle[dot]com
>>
>>
>>
On Fri, Aug 21, 2009 at 02:46:28PM -0400, Chuck Lever wrote:
> On Aug 21, 2009, at 2:24 PM, J. Bruce Fields wrote:
>> On Fri, Aug 21, 2009 at 02:16:08PM -0400, Chuck Lever wrote:
>>> I want to understand the server bug a little more. I glanced over
>>> RFC
>>> 2623 and didn't see anything specific.
>>>
>>> Is it the case that only Linux NFSD does this, or do other servers do
>>> it? In other words, is this a typical server response, and if so, is
>>> there a specific semantic attached to it?
>>>
>>> If no list is provided, should the client assume that only AUTH_NONE
>>> and
>>> AUTH_SYS are supported, or instead, perhaps that the client can try
>>> to
>>> use any flavor? In other words, if no list is provided, let the
>>> mount
>>> proceed no matter what was specified by sec= ?
>>
>> I think the safest behavior on the client would be something like:
>>
>> - If an explicit sec= is provided on the client, try that
>> flavor. Otherwise:
>> - If the server returned a nonempty list, pick something
>> off that list. Otherwise:
>> - Try auth_sys.
>
> Right now, we use AUTH_SYS if the mount command didn't specify a flavor,
> but the flavor we're going to use is always checked against the server's
> returned list. You seem to be suggesting we should ignore the server's
> list entirely if sec= was specified...?
Yes. I can't see what practical problems that would cause.
Also, while I hope this is the last bug in the mountd's flavor list
return, it isn't the first--only recently did we even start using real
information from the export instead of just faking something up. So I
think it's safest to preserve the historical sec= behavior and give
users a way to override the negotiation, to cut down on bug reports of
mount failures on upgrade.
--b.
J. Bruce Fields wrote:
>
>> Right now, we use AUTH_SYS if the mount command didn't specify a flavor,
>> but the flavor we're going to use is always checked against the server's
>> returned list. You seem to be suggesting we should ignore the server's
>> list entirely if sec= was specified...?
>>
>
> Yes. I can't see what practical problems that would cause.
>
> Also, while I hope this is the last bug in the mountd's flavor list
> return, it isn't the first--only recently did we even start using real
> information from the export instead of just faking something up. So I
> think it's safest to preserve the historical sec= behavior and give
> users a way to override the negotiation, to cut down on bug reports of
> mount failures on upgrade.
>
> --b.
>
While this Linux behavior occasionally bites the OpenSolaris behavior, it
really means we just have to guard against the client ignoring what we sent.
I.e., if I say we only support krb5 and you try with AUTH_SYS, I should
reject it.
Historical inertia is hard to overcome, but perhaps you could gradually
ease your way into using the real data. :->
On Aug 21, 2009, at 2:20 PM, J. Bruce Fields wrote:
> On Fri, Aug 21, 2009 at 02:16:08PM -0400, Chuck Lever wrote:
>> I want to understand the server bug a little more. I glanced over
>> RFC
>> 2623 and didn't see anything specific.
>>
>> Is it the case that only Linux NFSD does this, or do other servers do
>> it? In other words, is this a typical server response, and if so, is
>> there a specific semantic attached to it?
>>
>> If no list is provided, should the client assume that only
>> AUTH_NONE and
>> AUTH_SYS are supported, or instead, perhaps that the client can try
>> to
>> use any flavor? In other words, if no list is provided, let the
>> mount
>> proceed no matter what was specified by sec= ?
>
> I've sent the following to Steve to fix the server bug.
>
> --b.
>
> commit ceb3c96d68f47cf6a0c38ccd88b98c59c886e9fb
> Author: J. Bruce Fields <[email protected]>
> Date: Tue Jul 21 19:30:04 2009 -0400
>
> Don't give client an empty flavor list
>
> In the absence of an explicit sec= option on an export,
> rpc.mountd is
> returning a zero-length flavor list to clients in the MOUNT
> results.
>
> The linux client doesn't seem to mind, but the Solaris client
> (reasonably enough) is giving up; the symptom is a "security mode
> does
> not match" error on mount.
>
> We could modify the export-parsing code to ensure the secinfo
> array is
> nonzero. But I think it's slightly simpler to handle this
> default case
> in the implementation of the MOUNT call. This is more-or-less
> the same
> thing the kernel does when mountd passes it an export without any
> security flavors specified.
>
> Thanks to Tom Haynes for bug report and diagnosis.
>
> Signed-off-by: J. Bruce Fields <[email protected]>
>
> diff --git a/utils/mountd/mountd.c b/utils/mountd/mountd.c
> index b59f939..888fd8c 100644
> --- a/utils/mountd/mountd.c
> +++ b/utils/mountd/mountd.c
> @@ -359,6 +359,11 @@ static void set_authflavors(struct mountres3_ok
> *ok, nfs_export *exp)
> flavors[i] = s->flav->fnum;
> i++;
> }
> + if (i == 0) {
> + /* default when there is no sec= option: */
> + i = 1;
> + flavors[0] = AUTH_UNIX;
> + }
Does the Linux server also support AUTH_NONE if sec= isn't specified?
> ok->auth_flavors.auth_flavors_val = flavors;
> ok->auth_flavors.auth_flavors_len = i;
> }
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
On Aug 21, 2009, at 4:04 PM, J. Bruce Fields wrote:
> On Fri, Aug 21, 2009 at 02:46:28PM -0400, Chuck Lever wrote:
>> On Aug 21, 2009, at 2:24 PM, J. Bruce Fields wrote:
>>> On Fri, Aug 21, 2009 at 02:16:08PM -0400, Chuck Lever wrote:
>>>> I want to understand the server bug a little more. I glanced over
>>>> RFC
>>>> 2623 and didn't see anything specific.
>>>>
>>>> Is it the case that only Linux NFSD does this, or do other
>>>> servers do
>>>> it? In other words, is this a typical server response, and if
>>>> so, is
>>>> there a specific semantic attached to it?
>>>>
>>>> If no list is provided, should the client assume that only
>>>> AUTH_NONE
>>>> and
>>>> AUTH_SYS are supported, or instead, perhaps that the client can try
>>>> to
>>>> use any flavor? In other words, if no list is provided, let the
>>>> mount
>>>> proceed no matter what was specified by sec= ?
>>>
>>> I think the safest behavior on the client would be something like:
>>>
>>> - If an explicit sec= is provided on the client, try that
>>> flavor. Otherwise:
>>> - If the server returned a nonempty list, pick something
>>> off that list. Otherwise:
>>> - Try auth_sys.
>>
>> Right now, we use AUTH_SYS if the mount command didn't specify a
>> flavor,
>> but the flavor we're going to use is always checked against the
>> server's
>> returned list. You seem to be suggesting we should ignore the
>> server's
>> list entirely if sec= was specified...?
>
> Yes. I can't see what practical problems that would cause.
Well, it would mean our client isn't up to spec, confusing people who
need to modify that code and people who expect a sec=krb5 mount to
fail immediately if the server says it can't support AUTH_GSS_KRB5.
It may also not match the behavior of the legacy mount command on Linux.
> Also, while I hope this is the last bug in the mountd's flavor list
> return, it isn't the first--only recently did we even start using real
> information from the export instead of just faking something up. So I
> think it's safest to preserve the historical sec= behavior and give
> users a way to override the negotiation, to cut down on bug reports of
> mount failures on upgrade.
OK, if this is a recently introduced server problem, then why do we
need to adjust client-side behavior? Trond's response in cases like
this is usually "fix the d*mn server," which you've already done.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
On Fri, 2009-08-21 at 16:36 -0400, Chuck Lever wrote:
> On Aug 21, 2009, at 4:04 PM, J. Bruce Fields wrote:
> > Also, while I hope this is the last bug in the mountd's flavor list
> > return, it isn't the first--only recently did we even start using real
> > information from the export instead of just faking something up. So I
> > think it's safest to preserve the historical sec= behavior and give
> > users a way to override the negotiation, to cut down on bug reports of
> > mount failures on upgrade.
>
> OK, if this is a recently introduced server problem, then why do we
> need to adjust client-side behavior? Trond's response in cases like
> this is usually "fix the d*mn server," which you've already done.
What is the definition of "recently introduced" here? What is the exact
commit that introduced the bug in nfs-utils?
The problem is that we're changing the client, and if it turns out that
every damned Linux server that was installed out there in the past 2
years displays this bug, then Linus will call 'regression' on us and
revert the code.
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
[email protected]
http://www.netapp.com