On 18 Jul 2016, at 8:39, Lennart Poettering wrote: > Heya! > > I'd like to start a discussion regarding the "nobody" user on Fedora, > and propose that we change its definition sooner or later. I am not > proposing a feature according to the feature process for this yet, but > my hope is that these discussions will lead to one eventually. > > Most distributions (in particular Debian/Ubuntu-based ones) map the > user "nobody" to UID 65534. I think we should change Fedora to do the > same. Background: > > On Linux two UIDs are special: that's UID 0 for root, which is the > privileged user we all know. And then there's UID 65534 > (i.e. (uint16_t) -2), which is less well known. The Linux kernel calls > it the "overflow" UID. It has four purposes: > > 1. The kernel maps UIDs > 65535 to it when when some subsystem/API/fs > only supports 16bit UIDs, but a 32bit UID is passed to it. > > 2. it's used by the kernel's user namespacing as a the internal UID > that external UIDs are mapped to that don't have any local mapping. > > 3. It's used by NFS for all user IDs that cannot be mapped locally if > UID mapping is enabled. > > 4. One upon a time some system daemons chose to run as the "nobody" > user, instead of a proper system user of their own. But this is > universally frowned upon, and isn't done on any current systems > afaics. In fact, to my knowledge Fedora even prohibits this > explicitly in its policy (?). > > The uses 1-3 are relevant today, use 4 is clearly obsolete > afaics. Uses 1-3 can be subsumed pretty nicely as "the UID something > that cannot be mapped properly is mapped to". I think this is a good proposal, but the work would be in making sure use 4 really is obsolete since the big change here would be redefining what that "nobody" means. Right now, "nobody" is a real local account that scripts and daemons have used to sandbox themselves, and sometimes we can even find stuff like uid == 99 in conditionals. It's important to NFS that when passing file owner name strings between clients and servers the string "nobody" means the unmappable user, and not a real user of lowest privilege. If we make the change to redefine what the local user "nobody" means, we should make sure use 4 is obsolete. Otherwise, NFS is pretty flexible about being able to configure uid/name mappings, and I don't see a problem for NFS in changing -2 from nfsnobody to nobody. > On Fedora, we currently have a "nobody" user that is defined to UID > 99. It's defined unconditionally like this. To my knowledge there's no > actual use of this user at all in Fedora however. After a quick grep, Lustre has a #define NOBODY_UID 99 I don't know how that's used.. > The UID 65514 carries no name by default on Fedora, but as soon as you > install the NFS utils it gets mapped to the "nfsnobody" user name, > misleadingly indicating that it would be used only by NFS even though it's > a much more general concept. I figure the NFS guys adopted the name > "nfsnobody" for this, simply because "nobody" was already taken by UID 99 > on Fedora, unlike on other distributions. Likely, yes -- but maybe some of the other NFS people know more of the history. > In the context of user namespacing the UID 65534 appears a lot more > often as owner of various files. For example, if you turn on user > namespacing in typical container managers you'll notice that a ton of > files in /proc will then be owned by this user. Very confusingly, in a > container that includes the NFS utils all those files actually show up > as "nfsnobody"-owned now, even though there's no relation to NFS at all > for them. > > I'd like to propose that we clean this up, and just make Fedora work > like all other distributions. After all the reason of having this > special UID in the first place is to sidestep mapping problems between > different UID "realms". Hence I think it would be wise to at least > make the name of this very special UID somewhat more stable and > well-defined between distributions. > > I think this is of particular relevance as Debian/Ubuntu-based > container images tend to be substantially more popular than > Fedora-based ones, and hence I think we should try to unify at least > the names and semantics of the two special UIDs all distros have, to > minimize mapping problems and making user interaction in containers a > bit more friendly. > > You might ask of course, why Fedora should change to adopt > Debian's/Ubuntu's definition, instead of conversely making them adopt > Fedora's definition? Well, that's simple: Debian's definition makes a > lot more sense than Fedora's. And nothing we ship actually makes use > of FEdora's definition afaics, and we currently carry a workaround > called "nfsnobody" in some cases to avoid having to fix this properly. > > Another option would be to define an entirely new user name for 65534, > for example "void" or so. But quite frankly, that sounds like a > pointless bikeshedding excercise, and creates even more confusion, > balkanization and political hassles if you'd try to convince other > distros to adopt the same scheme too. > > Hence, let's go for "nobody == 65534" on Fedora too! And let's unify > the various dsitributions a tiny bit more, on this specific aspect. > > How could a transition look like? I figure new installs should get > "nobody" defined to 65534. Old installs should keep the old > definitions in place instead. The NFS packages should be updated to > not create the "nfsnobody" user if there's already another user mapped > to 65534 (maybe it already does that?). It should, since if nfsnobody does not exist it does: /usr/sbin/useradd -l -c "Anonymous NFS User" -r -g 65534 -s /sbin/nologin -u 65534 -d /var/lib/nfs nfsnobody .. which should fail with "useradd: UID 65534 is not unique".. Ben > Of course it's not pretty if old and new systems use different definitions > for this user, but I think it's not too much of a real-life issue, as most > code that refers to this group already does so by UID instead of name, > simply because the name is not stable across distributions. > > Opinions? > > Lennart > > -- > Lennart Poettering, Red Hat > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
