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

[Ian Kaufman]

Yes, I oversimplified things. The issue is that AUTH_SYS/AUTH_UNIX
does not support NFSv4. AUTH_SYS uses the UID, not the name, so the
mapping fails. So, when RPC uses AUTH_SYS, NFSv4 is SOL.

http://thread.gmane.org/gmane.linux.nfsv4/7103/focus=7105

Supposedly. at least on the client side, this has been fixed somewhere
upstream. However, the server side is not.

https://bugzilla.linux-nfs.org/show_bug.cgi?id=226

Regardless, my point is that this is not a Solaris/Linux issue, as a
Linux server and Linux clients would be in the same boat.

On Mon, Dec 8, 2014 at 12:23 PM, Paul B. Henson <henson at acm.org> wrote:
>> 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...
>
>



-- 
Ian Kaufman
Research Systems Administrator
UC San Diego, Jacobs School of Engineering ikaufman AT ucsd DOT edu