Bug 1537262 - Rename "nobody" user
Summary: Rename "nobody" user
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Changes Tracking
Version: 28
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Zbigniew Jędrzejewski-Szmek
QA Contact:
URL:
Whiteboard: ChangeAcceptedF28,SystemWideChange
Depends On: 1547932 1548050
Blocks: 1591969
TreeView+ depends on / blocked
 
Reported: 2018-01-22 19:09 UTC by Jan Kurik
Modified: 2018-06-15 21:49 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1591969 (view as bug list)
Environment:
Last Closed: 2018-05-02 12:04:21 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1488897 None CLOSED [nfs-utils] create group and user nfsnobody fail when install nfs-utils 2019-09-25 12:36:23 UTC

Internal Links: 1488897

Description Jan Kurik 2018-01-22 19:09:07 UTC
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.

Comment 1 Jan Kurik 2018-02-20 14:10:01 UTC
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.

Comment 2 Fedora End Of Life 2018-02-20 15:39:25 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

Comment 3 Zbigniew Jędrzejewski-Szmek 2018-02-21 17:31:49 UTC
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.

Comment 4 Zbigniew Jędrzejewski-Szmek 2018-02-22 10:17:46 UTC
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).

Comment 5 Jan Kurik 2018-03-06 08:57:36 UTC
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

Comment 6 Zbigniew Jędrzejewski-Szmek 2018-03-08 14:41:38 UTC
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.

Comment 7 Tim Niemueller 2018-04-13 09:41:38 UTC
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.


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