Bug 1350526

man user_namespaces:

Unmapped user and group IDs
       
There are various places where an unmapped user ID (group ID) may be
exposed to user space.  For example, the first process in a new user
namespace may  call  getuid()  before  a user  ID  mapping has been
defined for the namespace.  In most such cases, an unmapped user ID is
converted to the overflow user ID (group ID); the default value for
the overflow user ID (group ID) is 65534.  See the descriptions of
/proc/sys/kernel/overflowuid and /proc/sys/kernel/overflowgid in
proc(5).


So it seems all works as expected, NOTABUG from my point of view.


The question is if "nfsnobody" in /etc/passwd is the right name for so generic UID. Maybe it would be better to use anything else, but I have no clue about consequences for NFS.

Package setup doesn't create nfsnobody user. It is (probably) created by nfs-utils package - based on the uidgid file reservation. TBH, I don't know what is the reason behind using this specific uid/gid for it - LSB asks for user nobody (and this is created by setup package as uid/gid 99 (see https://git.fedorahosted.org/cgit/setup.git/plain/passwd for default users on Fedora and http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/usernames.html#TBL-OPTUSERS LSB for optional names and groups ). My expectation is that 65534 uid/gid for nfsnobody is related to consistency between ubuntu, fedora and maybe other distros.

For me, NOTABUG as well - but reassiging further - to nfs-utils .

The NFS server has long used 65534/nfsnobody as the default uid for remote root users.  See the "User ID Mapping" section of the exports(5) man page for more details.

The NFS behavior has a long history, and a change would come with some risk of disruption.  I can understand that this new use of the name could be confusing.  Without identifying some more concrete problem, though, I think we've got insufficient justification for a change.

Also include to NOTABUG.

I think when creating a user namespaces and not mapping root we could be confused by the "nfsnobody" name. From user_namespces(7) we know why the user namespaces use such a default name

   Unmapped user and group IDs
       There  are  various  places where an unmapped user ID (group ID) may be
       exposed to user space.  For example, the first process in  a  new  user
       namespace  may  call getuid() before a user ID mapping has been defined
       for the namespace.  In most such cases, an unmapped  user  ID  is  con‐
       verted  to  the  overflow user ID (group ID); the default value for the
       overflow user  ID  (group  ID)  is  65534.   See  the  descriptions  of
       /proc/sys/kernel/overflowuid    and   /proc/sys/kernel/overflowgid   in
       proc(5).

We need a solution that let us

1. the default user name and group name should make sense in the new user namespaces
2. the default name and group name should not break nfs-* components

I would argue that any user namespace setup which creates inside processes running with unmapped UIDs is in itself nonsensical (the process itself can’t tell its own UID from other unmapped UIDs), and simply incorrect.

And, if I am not mistaken, users _can_ set overflow[ug]id to something else than nfsnobody, however they want to name it.


Meanwhile, the semantics of traditional nfsnobody and the user namespace mapping failure are pretty equivalent, so it seems quite appropriate to use the same fake UID for both.


Anyway, what this seems to boil down to is a request to have the same UID show using two different names, and that is not going to happen, that would break far too many things. Change overflow[ug]id if you feel strongly about the naming.


Given the high amount of NOTABUG votes, let’s just close this I think.

(Also, passwd has absolutely nothing to do with account naming or allocation; it is just a dumb tool to call other infrastructure like PAM and libuser, and only manages existing accounts, does not determine policy or naming or file formats.  Reassigning back to setup as the closest we have for “account naming policy and registry”.)