AUTH_NONE at top of SECINFO_NONAME reply.

[NeilBrown <neilb@suse.com>]

[-- 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 --]