[OmniOS-discuss] NFSv4 id mapping only working on client but not server?

Paul B. Henson henson at acm.org
Mon Dec 8 20:23:20 UTC 2014


> From: Ian Kaufman
> Sent: Monday, December 08, 2014 8:54 AM
> 
> No, what we are saying is NFSv4 and RPC are not compatible right now,
> and thus AUTH_SYS/AUTH_UNIX will not map UIDs by name, but by number
> over RPC. If you are not going to use Kerberos or LDAP, then you need
> to sync UIDs/UIDNumber in /etc/passwd. It's not that Solaris and Linux
> are incompatible, it's that RPC does not support NFSv4.

Well, I don't think it's technically accurate to say NFSv4 and RPC are not
compatible, nor that RPC does not support NFSv4.

It's really more of an issue that the NFSv4 protocol failed to address ID
mapping completely for nonsecure RPC methods. For secure RPC (such as
Kerberos), identifiers are passed over the wire symbolically as strings, and
the ID mapper on each side translates them to numeric identifiers. However,
for insecure RPC using AUTH_SYS, NFSv4 continues to pass raw uid/gid
identifiers over the wire.

This limitation of the protocol renders ID mapping somewhat useless for
NFSv4 over insecure RPC :(. Ideally they could address it in v4.1 or v4.2 by
creating a new insecure AUTH_SYS_NAMES protocol, which would simply use
symbolic string identifiers over the wire like secure NFS does. I guess
there is not much interest or concern about this in the communities that
deal with NFS protocol specifications 8-/. Perhaps the majority of
deployments for people in decision-making capacity use secure NFS and thus
are not impacted by this deficiency...




More information about the OmniOS-discuss mailing list