On Do, 11.01.18 16:13, Steve Dickson (SteveD@xxxxxxxxxx) 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
