AUTH_NONE at top of SECINFO_NONAME reply.

AUTH_NONE at top of SECINFO_NONAME reply.

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 1406 bytes --]


Hi,
 I have an NFSv4.1 server (Netapp, don't know about version numbers)
 which responds to
    PUT_ROOTFH
    SECINFO_NONAME

with:

flavor: AUTH_NULL (0)
flavor: RPCSEC_GSS (6)
    service: rpcsec_gss_svc_integrity (2)
flavor: RPCSEC_GSS (6)
    service: rpcsec_gss_svc_none (1)
flavor: AUTH_UNIX (1)

This causes the Linux client to use AUTH_NULL, which doesn't end well
   Opcode: ACCESS (3), [Access Denied: RD LU MD XT DL]

I suspect this is a server bug, because the first flavor is meant to be
the most preferred.  However I wonder if there might be something else
going on.

1/ I note that for NFSv3 AUTH_NULL means something a bit different
  in this context:

	 * AUTH_NULL has a special meaning when it's in the server list - it
	 * means that the server will ignore the rpc creds, so any flavor
	 * can be used.

  Is there any chance that servers might reasonably expect that
  behavior for NFSv4.1 as well??

2/ In the pseudo-root filesystem it might make sense to use AUTH_NULL,
  providing something else is used when crossing in to another
  filesystem.
  Should the client send a new SECINFO when that happens (it may not
  help in this case, I don't know) or is that really only needed when
  NFS4ERR_WRONGSEC is returned?
  It seems a bit asymmetric that SECINFO is use pro-actively at the start
  of a session, but then only re-actively after that.

Any thoughts?

Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: AUTH_NONE at top of SECINFO_NONAME reply.

[J. Bruce Fields]

On Thu, Apr 14, 2016 at 09:33:22AM +1000, NeilBrown wrote:
>  I have an NFSv4.1 server (Netapp, don't know about version numbers)
>  which responds to
>     PUT_ROOTFH
>     SECINFO_NONAME
> 
> with:
> 
> flavor: AUTH_NULL (0)
> flavor: RPCSEC_GSS (6)
>     service: rpcsec_gss_svc_integrity (2)
> flavor: RPCSEC_GSS (6)
>     service: rpcsec_gss_svc_none (1)
> flavor: AUTH_UNIX (1)
> 
> This causes the Linux client to use AUTH_NULL, which doesn't end well
>    Opcode: ACCESS (3), [Access Denied: RD LU MD XT DL]
> 
> I suspect this is a server bug, because the first flavor is meant to be
> the most preferred.  However I wonder if there might be something else
> going on.
> 
> 1/ I note that for NFSv3 AUTH_NULL means something a bit different
>   in this context:
> 
> 	 * AUTH_NULL has a special meaning when it's in the server list - it
> 	 * means that the server will ignore the rpc creds, so any flavor
> 	 * can be used.
> 
>   Is there any chance that servers might reasonably expect that
>   behavior for NFSv4.1 as well??

I'll admit it seems a trap for the unwary implementor, but I think this
case is really clear:

	http://tools.ietf.org/html/rfc5661#section-18.29.3

	The result will contain an array that represents the security
	mechanisms available, with an order corresponding to the
	server's preferences, the most preferred being first in the
	array.  The client is free to pick whatever security mechanism
	it both desires and supports, or to pick in the server's
	preference order the first one it supports.

So we should be leaning on the server vendor to fix and/or explain
what's going on there.

> 2/ In the pseudo-root filesystem it might make sense to use AUTH_NULL,
>   providing something else is used when crossing in to another
>   filesystem.

One thing that bugs me about that is that the client could have been fed
forged replies while using AUTH_NULL, and after switching to, say,
krb5i, it may still be depending on those results (e.g., the lookups
that got you to that mountpoint), unless it's careful to recheck some
things.

There are probably assumptions under which that could still be useful,
but it starts to feel a bit delicate.  Anyway, that's a bit of a derail:

>   Should the client send a new SECINFO when that happens (it may not
>   help in this case, I don't know) or is that really only needed when
>   NFS4ERR_WRONGSEC is returned?
>   It seems a bit asymmetric that SECINFO is use pro-actively at the start
>   of a session, but then only re-actively after that.

Maybe.  I would have guessed that / is the point where you're most
likely to guess the security flavor wrong.  I'm not sure it really
matters which way you do it, though.  It's just one round trip plus or
minus on each mountpoint.

--b.

Re: AUTH_NONE at top of SECINFO_NONAME reply.

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 2648 bytes --]

On Tue, Apr 19 2016, J. Bruce Fields wrote:

> On Thu, Apr 14, 2016 at 09:33:22AM +1000, NeilBrown wrote:
>>  I have an NFSv4.1 server (Netapp, don't know about version numbers)
>>  which responds to
>>     PUT_ROOTFH
>>     SECINFO_NONAME
>> 
>> with:
>> 
>> flavor: AUTH_NULL (0)
>> flavor: RPCSEC_GSS (6)
>>     service: rpcsec_gss_svc_integrity (2)
>> flavor: RPCSEC_GSS (6)
>>     service: rpcsec_gss_svc_none (1)
>> flavor: AUTH_UNIX (1)
>> 
>> This causes the Linux client to use AUTH_NULL, which doesn't end well
>>    Opcode: ACCESS (3), [Access Denied: RD LU MD XT DL]
>> 
>> I suspect this is a server bug, because the first flavor is meant to be
>> the most preferred.  However I wonder if there might be something else
>> going on.
>> 
>> 1/ I note that for NFSv3 AUTH_NULL means something a bit different
>>   in this context:
>> 
>> 	 * AUTH_NULL has a special meaning when it's in the server list - it
>> 	 * means that the server will ignore the rpc creds, so any flavor
>> 	 * can be used.
>> 
>>   Is there any chance that servers might reasonably expect that
>>   behavior for NFSv4.1 as well??
>
> I'll admit it seems a trap for the unwary implementor, but I think this
> case is really clear:
>
> 	http://tools.ietf.org/html/rfc5661#section-18.29.3
>
> 	The result will contain an array that represents the security
> 	mechanisms available, with an order corresponding to the
> 	server's preferences, the most preferred being first in the
> 	array.  The client is free to pick whatever security mechanism
> 	it both desires and supports, or to pick in the server's
> 	preference order the first one it supports.
>
> So we should be leaning on the server vendor to fix and/or explain
> what's going on there.

That was the direction I was leaning, but it is nice to have it
confirmed - particularly given the interesting rules with NFSv3.

My colleague subsequently discovered that there were setting on the
Netapp which could change the behavior.   He fiddled things and the
problem went away, but he noted:

	On the netapp side, I have three of these settings: rorule,rwrule,superuser, and for
	each of these I can set
	from the list: "any   none  krb5  krb5i ntlm  sys". So with
	"ro=sys,rw=none,superuser=any" I'm still in the
	situation where I can get the AUTH_NULL first ...

("AUTH_NULL first" being the problematic situation).
I wonder if "none" means "no authentication needed" or "no access
given".

Still seems strange behavior for the server, but as it can be avoided it
probably isn't worth any more consideration.

Thanks a lot,

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: AUTH_NONE at top of SECINFO_NONAME reply.

[Trond Myklebust]

DQoNCg0KDQoNCk9uIDQvMTkvMTYsIDE3OjI0LCAiTmVpbEJyb3duIiA8bGludXgtbmZzLW93bmVy
QHZnZXIua2VybmVsLm9yZyBvbiBiZWhhbGYgb2YgbmVpbGJAc3VzZS5jb20+IHdyb3RlOg0KDQo+
T24gVHVlLCBBcHIgMTkgMjAxNiwgSi4gQnJ1Y2UgRmllbGRzIHdyb3RlOg0KPg0KPj4gT24gVGh1
LCBBcHIgMTQsIDIwMTYgYXQgMDk6MzM6MjJBTSArMTAwMCwgTmVpbEJyb3duIHdyb3RlOg0KPj4+
ICBJIGhhdmUgYW4gTkZTdjQuMSBzZXJ2ZXIgKE5ldGFwcCwgZG9uJ3Qga25vdyBhYm91dCB2ZXJz
aW9uIG51bWJlcnMpDQo+Pj4gIHdoaWNoIHJlc3BvbmRzIHRvDQo+Pj4gICAgIFBVVF9ST09URkgN
Cj4+PiAgICAgU0VDSU5GT19OT05BTUUNCj4+PiANCj4+PiB3aXRoOg0KPj4+IA0KPj4+IGZsYXZv
cjogQVVUSF9OVUxMICgwKQ0KPj4+IGZsYXZvcjogUlBDU0VDX0dTUyAoNikNCj4+PiAgICAgc2Vy
dmljZTogcnBjc2VjX2dzc19zdmNfaW50ZWdyaXR5ICgyKQ0KPj4+IGZsYXZvcjogUlBDU0VDX0dT
UyAoNikNCj4+PiAgICAgc2VydmljZTogcnBjc2VjX2dzc19zdmNfbm9uZSAoMSkNCj4+PiBmbGF2
b3I6IEFVVEhfVU5JWCAoMSkNCj4+PiANCj4+PiBUaGlzIGNhdXNlcyB0aGUgTGludXggY2xpZW50
IHRvIHVzZSBBVVRIX05VTEwsIHdoaWNoIGRvZXNuJ3QgZW5kIHdlbGwNCj4+PiAgICBPcGNvZGU6
IEFDQ0VTUyAoMyksIFtBY2Nlc3MgRGVuaWVkOiBSRCBMVSBNRCBYVCBETF0NCj4+PiANCj4+PiBJ
IHN1c3BlY3QgdGhpcyBpcyBhIHNlcnZlciBidWcsIGJlY2F1c2UgdGhlIGZpcnN0IGZsYXZvciBp
cyBtZWFudCB0byBiZQ0KPj4+IHRoZSBtb3N0IHByZWZlcnJlZC4gIEhvd2V2ZXIgSSB3b25kZXIg
aWYgdGhlcmUgbWlnaHQgYmUgc29tZXRoaW5nIGVsc2UNCj4+PiBnb2luZyBvbi4NCj4+PiANCj4+
PiAxLyBJIG5vdGUgdGhhdCBmb3IgTkZTdjMgQVVUSF9OVUxMIG1lYW5zIHNvbWV0aGluZyBhIGJp
dCBkaWZmZXJlbnQNCj4+PiAgIGluIHRoaXMgY29udGV4dDoNCj4+PiANCj4+PiAJICogQVVUSF9O
VUxMIGhhcyBhIHNwZWNpYWwgbWVhbmluZyB3aGVuIGl0J3MgaW4gdGhlIHNlcnZlciBsaXN0IC0g
aXQNCj4+PiAJICogbWVhbnMgdGhhdCB0aGUgc2VydmVyIHdpbGwgaWdub3JlIHRoZSBycGMgY3Jl
ZHMsIHNvIGFueSBmbGF2b3INCj4+PiAJICogY2FuIGJlIHVzZWQuDQo+Pj4gDQo+Pj4gICBJcyB0
aGVyZSBhbnkgY2hhbmNlIHRoYXQgc2VydmVycyBtaWdodCByZWFzb25hYmx5IGV4cGVjdCB0aGF0
DQo+Pj4gICBiZWhhdmlvciBmb3IgTkZTdjQuMSBhcyB3ZWxsPz8NCj4+DQo+PiBJJ2xsIGFkbWl0
IGl0IHNlZW1zIGEgdHJhcCBmb3IgdGhlIHVud2FyeSBpbXBsZW1lbnRvciwgYnV0IEkgdGhpbmsg
dGhpcw0KPj4gY2FzZSBpcyByZWFsbHkgY2xlYXI6DQo+Pg0KPj4gCWh0dHA6Ly90b29scy5pZXRm
Lm9yZy9odG1sL3JmYzU2NjEjc2VjdGlvbi0xOC4yOS4zDQo+Pg0KPj4gCVRoZSByZXN1bHQgd2ls
bCBjb250YWluIGFuIGFycmF5IHRoYXQgcmVwcmVzZW50cyB0aGUgc2VjdXJpdHkNCj4+IAltZWNo
YW5pc21zIGF2YWlsYWJsZSwgd2l0aCBhbiBvcmRlciBjb3JyZXNwb25kaW5nIHRvIHRoZQ0KPj4g
CXNlcnZlcidzIHByZWZlcmVuY2VzLCB0aGUgbW9zdCBwcmVmZXJyZWQgYmVpbmcgZmlyc3QgaW4g
dGhlDQo+PiAJYXJyYXkuICBUaGUgY2xpZW50IGlzIGZyZWUgdG8gcGljayB3aGF0ZXZlciBzZWN1
cml0eSBtZWNoYW5pc20NCj4+IAlpdCBib3RoIGRlc2lyZXMgYW5kIHN1cHBvcnRzLCBvciB0byBw
aWNrIGluIHRoZSBzZXJ2ZXIncw0KPj4gCXByZWZlcmVuY2Ugb3JkZXIgdGhlIGZpcnN0IG9uZSBp
dCBzdXBwb3J0cy4NCj4+DQo+PiBTbyB3ZSBzaG91bGQgYmUgbGVhbmluZyBvbiB0aGUgc2VydmVy
IHZlbmRvciB0byBmaXggYW5kL29yIGV4cGxhaW4NCj4+IHdoYXQncyBnb2luZyBvbiB0aGVyZS4N
Cj4NCj5UaGF0IHdhcyB0aGUgZGlyZWN0aW9uIEkgd2FzIGxlYW5pbmcsIGJ1dCBpdCBpcyBuaWNl
IHRvIGhhdmUgaXQNCj5jb25maXJtZWQgLSBwYXJ0aWN1bGFybHkgZ2l2ZW4gdGhlIGludGVyZXN0
aW5nIHJ1bGVzIHdpdGggTkZTdjMuDQo+DQo+TXkgY29sbGVhZ3VlIHN1YnNlcXVlbnRseSBkaXNj
b3ZlcmVkIHRoYXQgdGhlcmUgd2VyZSBzZXR0aW5nIG9uIHRoZQ0KPk5ldGFwcCB3aGljaCBjb3Vs
ZCBjaGFuZ2UgdGhlIGJlaGF2aW9yLiAgIEhlIGZpZGRsZWQgdGhpbmdzIGFuZCB0aGUNCj5wcm9i
bGVtIHdlbnQgYXdheSwgYnV0IGhlIG5vdGVkOg0KPg0KPglPbiB0aGUgbmV0YXBwIHNpZGUsIEkg
aGF2ZSB0aHJlZSBvZiB0aGVzZSBzZXR0aW5nczogcm9ydWxlLHJ3cnVsZSxzdXBlcnVzZXIsIGFu
ZCBmb3INCj4JZWFjaCBvZiB0aGVzZSBJIGNhbiBzZXQNCj4JZnJvbSB0aGUgbGlzdDogImFueSAg
IG5vbmUgIGtyYjUgIGtyYjVpIG50bG0gIHN5cyIuIFNvIHdpdGgNCj4JInJvPXN5cyxydz1ub25l
LHN1cGVydXNlcj1hbnkiIEknbSBzdGlsbCBpbiB0aGUNCj4Jc2l0dWF0aW9uIHdoZXJlIEkgY2Fu
IGdldCB0aGUgQVVUSF9OVUxMIGZpcnN0IC4uLg0KPg0KPigiQVVUSF9OVUxMIGZpcnN0IiBiZWlu
ZyB0aGUgcHJvYmxlbWF0aWMgc2l0dWF0aW9uKS4NCj5JIHdvbmRlciBpZiAibm9uZSIgbWVhbnMg
Im5vIGF1dGhlbnRpY2F0aW9uIG5lZWRlZCIgb3IgIm5vIGFjY2Vzcw0KPmdpdmVuIi4NCg0KQSBj
ZXJ0YWluIHRob21hc0BuZXRhcHAuY29tIGV4cGxhaW5lZCB0aGUgYmVoYXZpb3VyIHRodXM6DQoN
CiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25mc3Y0L2N1cnJlbnQvbXNn
MDk3NDMuaHRtbA0KDQpDaGVlcnMNCiAgVHJvbmQNCg==

Re: AUTH_NONE at top of SECINFO_NONAME reply.

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 421 bytes --]

On Wed, Apr 20 2016, Trond Myklebust <trondmy@primarydata.com> wrote:

> On 4/19/16, 17:24, "NeilBrown" <linux-nfs-owner@vger.kernel.org on behalf of neilb@suse.com> wrote:
>
>>I wonder if "none" means "no authentication needed" or "no access
>>given".
>
> A certain thomas@netapp.com explained the behaviour thus:
>
>  https://www.ietf.org/mail-archive/web/nfsv4/current/msg09743.html
>

Ahhh, cool.  Thanks!

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]