Bug 1350526 - Th default login name and group name -- "nfsnobody" -- in new user namespaces make no sense
Summary: Th default login name and group name -- "nfsnobody" -- in new user namespaces...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: setup
Version: 24
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ondrej Vasik
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-06-27 16:24 UTC by Xibo Ning
Modified: 2016-07-04 08:01 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-07-04 08:01:29 UTC
Type: Bug


Attachments (Terms of Use)

Description Xibo Ning 2016-06-27 16:24:12 UTC
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:

Comment 1 Karel Zak 2016-06-27 17:35:23 UTC
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.

Comment 2 Ondrej Vasik 2016-06-27 19:04:55 UTC
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 .

Comment 3 J. Bruce Fields 2016-06-27 20:06:58 UTC
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.

Comment 4 Xibo Ning 2016-06-28 00:50:49 UTC
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).

Comment 5 Xibo Ning 2016-06-28 01:20:58 UTC
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

Comment 6 Miloslav Trmač 2016-07-04 08:01:29 UTC
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”.)


Note You need to log in before you can comment on or make changes to this bug.