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