This is a tracking bug for Change: Rename "nobody" user For more details, see: https://fedoraproject.org/wiki/Changes/RenameNobodyUser Use "nobody:nobody" as the names for the kernel overflow UID:GID pair, and retire the old "nfsnobody" name and the old "nobody:nobody" pair with 99:99 numbers.
On 2018-Feb-20, we have reached the Fedora 28 Change Checkpoint: Completion deadline (testable). At this point, all accepted changes should be substantially complete, and testable. Additionally, if a change is to be enabled by default, it must be enabled at Change Completion deadline as well. Change tracking bug should be set to the MODIFIED state to indicate it achieved completeness. Incomplete and non testable Changes will be reported to FESCo for 2018-Feb-23 meeting.
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'.
The systemd side is done: both upstream and in Fedora packaging. systemd-237-3.git84c8da5.fc28 has the necessary bits, including /usr/lib/systemd/purge-nobody-user which can be used to check and convert existing systems (I'll update "How to test" on the Change page). Some other bits are missing, in particular a pull request for setup.rpm to make this the default is open at https://pagure.io/setup/pull-request/10. So... this is testable, but not complete.
OK, this is definitely testable with the latest systemd. I'm adding a bug on libvirt as a dependency for tracking, but it's not really blocking for this change (libvirt is as broken now as it was before).
On 2018-Mar-08 we reached the "Change Checkpoint: 100% Code Complete Deadline" milestone for Fedora 28 release. At this point all the Changes not at least in "ON_QA" state should be brought to FESCo for review. Please update the state of this bug to "ON_QA" if it is already 100% completed. Please let me know in case you have any trouble with the implementation and the Change needs any help or review. Thanks, Jan
setup-2.11.3-1.fc28 has been built with the change, and is in F28 beta. dnsmasq and libvirt have been fixed to not use nobody. Things are moving in the right direction.
Could we be hit by early fallout on F27 in #1488897? The nfs-utils scriptlet as well as manual useradd for 65534 fail even though no user exists in /etc/passwd. Useradd has the confusing message that the user already exists (but it doesn't). The original issue we are seeing seems to be directly related to why this change is made (and we welcome it!): mount volume into container, this creates files with the overflow ID, create user to allow proper owner setting through ansible, use nfs-utils package since that defines this user up until F27. The question is, is this expected behavior on F27 and is there a known workaround? For now we resort to lineinfile changes to /etc/passwd.