Norbert Aschendorff | 23 Aug 11:21 2012
Picon

NFSv4, Name (string) mapping vs. raw UID, idmapd and Kernels >= 3.3

Hi all,
I recently opened a thread on freebsd-stable about problems with the
mapping of UIDs to user strings (user <at> domain form) in NFSv4 packets
running newer kernels:
[http://www.mail-archive.com/freebsd-stable-h+KGxgPPiopAfugRpC6u6w <at> public.gmane.org/index.html#122549]
In
[http://www.mail-archive.com/freebsd-stable-h+KGxgPPiopAfugRpC6u6w <at> public.gmane.org/msg122571.html],
Rick says that the described issue may be related to the NFSv4/NFSv4.1
RFCs which deny/allow sending "raw" numeric UIDs (1000 instead of
"user <at> domain").
The problem is that Linux kernels newer than 3.2 (the last working
kernel, on both Debian and Fedora; I've tested 3.3, 3.4 and 3.5) send
these numeric UIDs/GIDs [1] which, as it's described in the mentioned
email, may be convenient when mounting NFSv4 filesystems as root
filesystem (at a point where an idmapd/nfsuserd (on FreeBSD) isn't
already running) and numeric UIDs/GIDs are required (because of the
early stage)
Now it could be that Kernels newer than 3.2 (>= 3.3) support this
feature (which is said to appear in NFSv4.1) already - and FreeBSD 9.0
does not (it shows 32767 as UID - due to that I discovered this issue; a
Fedora 17/k3.5 system supports the numeric UIDs/GIDs without any problems).

--> 1. Is this assumption correct? Or is it a bug as filed here:
[https://bugzilla.novell.com/show_bug.cgi?id=756897]

--> 2. As Rick says finally in
[http://www.mail-archive.com/freebsd-stable-h+KGxgPPiopAfugRpC6u6w <at> public.gmane.org/msg122572.html],
it would be cool if this behavior was tunable. Is it tunable via options
in /etc/exports? Or in idmapd.conf? (The man pages don't describe such
directives (at least at the first look)).
(Continue reading)

J. Bruce Fields | 23 Aug 16:46 2012

Re: NFSv4, Name (string) mapping vs. raw UID, idmapd and Kernels >= 3.3

Adding Rick to the cc:

On Thu, Aug 23, 2012 at 11:21:29AM +0200, Norbert Aschendorff wrote:
> I recently opened a thread on freebsd-stable about problems with the
> mapping of UIDs to user strings (user <at> domain form) in NFSv4 packets
> running newer kernels:
> [http://www.mail-archive.com/freebsd-stable-h+KGxgPPiopAfugRpC6u6w <at> public.gmane.org/index.html#122549]
> In
> [http://www.mail-archive.com/freebsd-stable-h+KGxgPPiopAfugRpC6u6w <at> public.gmane.org/msg122571.html],
> Rick says that the described issue may be related to the NFSv4/NFSv4.1
> RFCs which deny/allow sending "raw" numeric UIDs (1000 instead of
> "user <at> domain").
> The problem is that Linux kernels newer than 3.2 (the last working
> kernel, on both Debian and Fedora; I've tested 3.3, 3.4 and 3.5) send
> these numeric UIDs/GIDs [1] which, as it's described in the mentioned
> email, may be convenient when mounting NFSv4 filesystems as root
> filesystem (at a point where an idmapd/nfsuserd (on FreeBSD) isn't
> already running) and numeric UIDs/GIDs are required (because of the
> early stage)
> Now it could be that Kernels newer than 3.2 (>= 3.3) support this
> feature (which is said to appear in NFSv4.1) already - and FreeBSD 9.0
> does not (it shows 32767 as UID - due to that I discovered this issue; a
> Fedora 17/k3.5 system supports the numeric UIDs/GIDs without any problems).

Yes, newer linux servers by default do return numeric ID's (unless
kerberos is used).

> --> 1. Is this assumption correct? Or is it a bug as filed here:
> [https://bugzilla.novell.com/show_bug.cgi?id=756897]

(Continue reading)

Norbert Aschendorff | 23 Aug 17:04 2012
Picon

Re: NFSv4, Name (string) mapping vs. raw UID, idmapd and Kernels >= 3.3

Thank you very much for that information :)

Norbert
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Rick Macklem | 24 Aug 02:25 2012
Picon

Re: NFSv4, Name (string) mapping vs. raw UID, idmapd and Kernels >= 3.3

J. Bruce Fields wrote:
> Adding Rick to the cc:
> 
> On Thu, Aug 23, 2012 at 11:21:29AM +0200, Norbert Aschendorff wrote:
> > I recently opened a thread on freebsd-stable about problems with the
> > mapping of UIDs to user strings (user <at> domain form) in NFSv4 packets
> > running newer kernels:
> > [http://www.mail-archive.com/freebsd-stable-h+KGxgPPiopAfugRpC6u6w <at> public.gmane.org/index.html#122549]
> > In
> > [http://www.mail-archive.com/freebsd-stable-h+KGxgPPiopAfugRpC6u6w <at> public.gmane.org/msg122571.html],
> > Rick says that the described issue may be related to the
> > NFSv4/NFSv4.1
> > RFCs which deny/allow sending "raw" numeric UIDs (1000 instead of
> > "user <at> domain").
> > The problem is that Linux kernels newer than 3.2 (the last working
> > kernel, on both Debian and Fedora; I've tested 3.3, 3.4 and 3.5)
> > send
> > these numeric UIDs/GIDs [1] which, as it's described in the
> > mentioned
> > email, may be convenient when mounting NFSv4 filesystems as root
> > filesystem (at a point where an idmapd/nfsuserd (on FreeBSD) isn't
> > already running) and numeric UIDs/GIDs are required (because of the
> > early stage)
> > Now it could be that Kernels newer than 3.2 (>= 3.3) support this
> > feature (which is said to appear in NFSv4.1) already - and FreeBSD
> > 9.0
> > does not (it shows 32767 as UID - due to that I discovered this
> > issue; a
> > Fedora 17/k3.5 system supports the numeric UIDs/GIDs without any
> > problems).
(Continue reading)

J. Bruce Fields | 25 Aug 00:02 2012

Re: NFSv4, Name (string) mapping vs. raw UID, idmapd and Kernels >= 3.3

On Thu, Aug 23, 2012 at 08:25:36PM -0400, Rick Macklem wrote:
> Then on the next page:
> 
>    To provide a greater degree of compatibility with previous versions
>    of NFS (i.e., v2 and v3), which identified users and groups by 32-bit
>    unsigned uid's and gid's, owner and group strings that consist of
>    decimal numeric values with no leading zeros can be given a special
>    interpretation by clients and servers which choose to provide such
>    support.  
>    ** The receiver may treat such a user or group string as
>    representing the same user as would be represented by a v2/v3 uid or
>    gid having the corresponding numeric value.  A server is not
>    obligated to accept such a string, but may return an NFS4ERR_BADOWNER
>    instead.  
>    --> To avoid this mechanism being used to subvert user and
>    group translation, so that a client might pass all of the owners and
>    groups in numeric form, a server SHOULD return an NFS4ERR_BADOWNER
>    error when there is a valid translation for the user or owner
>    designated in this way.  In that case, the client must use the
>    appropriate name <at> domain string and not the special form for
>    compatibility.
> 
> The sentence at "**" says a receiver "may" recognize the numeric uid/gid#
> string. This would suggest that a client isn't expected/required to do so,
> as I read it. (This page seems to be very confusing w.r.t. what clients/servers
> are expected/required to support.)
> The sentence at "-->" is a SHOULD (not a MUST, I admit) that seems to
> say a server should only allow numeric uid/gid# strings when there isn't
> a name<->uid/gid# translation and should avoid allowing clients to just
> use uid/gid# strings?
(Continue reading)


Gmane