Distributions

Mapping "nobody" in Fedora

The "nobody" user in Fedora is currently mapped to a different user ID (UID) value than some other distributions are using. In days gone past, that might not have been much of a concern, but with the advent of containers—cross-distribution containers in particular—there are reasons to consider making those IDs consistent. An RFC that was recently posted to the fedora-devel mailing list by Lennart Poettering argues for doing just that.

It turns out that there are two special UIDs in Linux. One of those is rather well-known—0 for the root user—but the other is, perhaps, almost unknown. The UID 65534 (i.e. one less than the maximum 16-bit unsigned number) is known as the "overflow UID" and it is used for a few specific purposes by the kernel. On Debian and Ubuntu systems, that UID is mapped to the nobody user, but Fedora uses UID 99 for nobody.

By default, the 65534 UID on Fedora is not mapped to any name. However, if the nfs-utils package gets installed, 65534 becomes "nfsnobody". As Poettering noted, that is confusing because it implies the UID is somehow specific to NFS, which is not the case. But that is only one of the things that the kernel uses the overflow UID for. If UID mapping is enabled for an NFS volume, the kernel will map UIDs that can't be locally mapped to the overflow UID, he said.

In addition, he listed two other uses for the overflow ID. If a filesystem or architecture only supports 16-bit UIDs, but a 32-bit UID comes from elsewhere, the kernel will map those values to the overflow UID. Also, inside a user namespace, any external UIDs that don't have an internal mapping will instead be mapped to the overflow UID. The value of the overflow UID can be changed using /proc/sys/fs/overflowuid, but that would likely lead to other problems, he said.

So Poettering suggested that Fedora find a way to map the overflow UID to nobody, in keeping with the other distributions. He noted that the overflow UID appears much more often inside user namespaces (for instance as the owner of various /proc files), which will either show up as simply "65534" or "nfsnobody" depending on whether the NFS utilities are installed. Furthermore:

He also noted that, historically, system daemons would sometimes run as nobody, but it is "universally frowned upon". From what he could tell, nothing in Fedora does that, and he thought it was explicitly prohibited by Fedora packaging policy. Poettering was mistaken about those last two items, however. Sam Varshavchik pointed out that both the dnsmasq and distccd daemons run as nobody and suspected there were more:

But Andrew Lutomirski said that the chroot() practice is insecure. Unless a PID namespace is also used, a process running as nobody can ptrace() another running as that user and escape the chroot(). Poettering wondered again if the practice is prohibited by the packaging guidelines, but James Hogarth looked into it and found nothing in those guidelines that did so. That led Poettering to file a Fedora packaging committee bug to try to resolve that.

In general, participants in the thread had favorable views about making the change, but one sticking point is a transition plan. Poettering suggested that new installs could get 65534 assigned to nobody and that the NFS utilities check for that assignment and not override it with nfsnobody. He said that most code should be using the numeric value anyway, since the names are not stable across distributions.

But Ondřej Vašík pointed to a bug that was filed about the nfsnobody user inside user namespaces, which was closed as "NOTABUG". Changing nfsnobody was deemed potentially disruptive in a comment by J. Bruce Fields on the bug. Fields further described some of those potential problems in a post in the thread. Access-control lists (ACLs) could change in surprising ways if nobody could map to 99 or 65534 on different systems, though that can already occur in mixed-distribution environments. He concluded:

Vašík was also concerned about scripts that rely on nfsnobody being present and that it maps to 65534, so eliminating that user could be problematic. Another possibility would be to have both nobody and nfsnobody map to 65534, as Zbigniew Jędrzejewski-Szmek described:

Filesystems store UID information as numbers, so putting nobody ahead of nfsnobody would simply change how ls and other tools report the owner. But for utilities like tar, there may still be a problem, as Nico Kadel-Garcia pointed out:

Simo Sorce is less concerned, though, noting that "breakage for some will be un-breakage for someone else". Being consistent with the kernel and other distributions is more important, Sorce said. One other potential problem was raised by Benjamin Coddington; some references to specific mappings might be buried in C code. For example, he found a definition of the nobody UID as 99 in the Lustre filesystem code, though it is not clear what it is being used for (and it would have to be specific to Fedora and a few other distributions that use that mapping).

At this point, no major opposition has materialized, though there is no real feature proposal on the table yet. It is a potentially disruptive change but, as Sorce, Poettering, and others said, there is value in being consistent with other distributions. The next step would be for someone to formally propose it as a feature, get it approved, and put it into Rawhide to soak for a time—when, or if, that happens remains to be seen.

Comments (7 posted)

Distribution quotes of the week

Comments (none posted)

Ubuntu 16.04.1 LTS released

Full Story (comments: none)

ARM ports and Cloud Images BoFs

Steve also summarizes the Cloud Images BoF. Topics include stuff we're currently doing, stuff we should be doing, official image requirements, a proposed sprint, documentation, tooling, and more.

Comments (none posted)

Fedora elections

Comments (none posted)

Distribution newsletters

• DistroWatch Weekly, Issue 671 (July 25)
• Lunar Linux weekly news (July 22)
• openSUSE news (July 27)
• openSUSE Tumbleweed – Review of the Week (July 24)
• Ubuntu Weekly Newsletter, Issue 475 (July 24)

Comments (none posted)

The newest version of OpenBSD closes potential security loopholes (InfoWorld)

Comments (25 posted)