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:
signature.asc
Description: PGP signature
