Description of problem: When creating a new user namespace and not mapping the current user to the superuser, the default login name and group name is "nfsnobody". This name make no sense because I didn't install any nfs-* components. Version-Release number of selected component (if applicable): util-linux-2.28-3.fc24.x86_64 How reproducible: Steps to Reproduce: 1. sudo unshare -m --mount-proc -p -f -U --map-root-user bash Actual results: [root@localhost nerd]# ls -l /tmp total 0 ... 2995c80c6eff41e48ee0e7eade920cbe-spice-vdagentd.service-U25qvY drwx------. 2 nfsnobody nfsnobody 40 Jun 28 00:13 tracker-extract-files.1000 Expected results: The login name and group name should be, e.g., "nobody", a name that make more sense. Additional info:
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”.)