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