On 4/19/16, 17:24, "NeilBrown" <linux-nfs-owner@xxxxxxxxxxxxxxx on behalf of neilb@xxxxxxxx> wrote: >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". A certain thomas@xxxxxxxxxx explained the behaviour thus: https://www.ietf.org/mail-archive/web/nfsv4/current/msg09743.html Cheers Trond ��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
