On Do, 11.01.18 16:13, Steve Dickson (SteveD(a)RedHat.com) wrote:
> This is problematic in a few different ways:
> * 65534:65534 is used by the kernel as the overflow identifier, when
> some UID cannot be represented in the current namespace. This applies
> to both NFS, but probably more commonly nowadays to UIDs outside of
> the current user namespace (e.g. when a file or process owned by a
> user from outside of a container). Calling this "nfsnobody" is
> misleading.
Misleading to Whom??? -2 has been used since the 80's
There has to be an uid/gid to map unknown uid/gid to.
I hope you are aware that user id 65534 is used by user namespacing
(i.e. CLONE_NEWUSER) too, and in that context is probably much more
prominently visible to users than in the NFS context. The fact that
the user/group is called "nfsnobody" is quite misleading if most users
see it only in the user namespacing context which has zero
relationship to NFS.
(Also, "-2" is not 65534. Since kernel 2.4 uid_t is 32bit on
Linux. That means "-2" translates to 4294967294, and not 65534. And
given that uid_t is defined as unsigned type on Linux it's kind
strange to even bother with negative values for this, that just
confuses everybody, including apparently yourself...)
> * the name for the overflow user is only defined when
nfs-utils.rpm is
> installed. In particular in containers people want to minimize the
> number of packages installed, so nfs-utils is likely not to be
> installed.
So if the nfs-utils is not installed... the id/gid will not be
created
Yes, and that's one of the issues we are trying to fix: the UID/GID is
used prominently, in the context of userns, but it either shows up as
not registered at all currently, or is assigned to NFS which is really
misleading.
> We propose to:
> * stop using nfsnobody for the overflow uid/gid names
> * stop using nobody for the static user 99 and group 99
> * use the nobody:nobody pair of names for 65534:65534
What are you going to replace it with?? When a server
gives a client a uid/gid that it does know about
the client has to uid/gid to map it to. Somebody has
to own the files.
We are not taking the concept of this user/group away. We are also not
taking the UID/GID assignment 65534 away, either. All we are doing is
assigning it a better name and do so unconditionally, independently of
whether nfsutils is installed or not, as the UID/GID 65534 has plenty
uses outside of NFS.
Lennart
--
Lennart Poettering, Red Hat