passwd: user "nobody" does not match expected Fedora UID/GID

[lucab]

It looks like FCOS currently ships an hardcoded nobody user&group with UID and GID equal to 99:

# grep ^nobody /usr/lib/passwd
nobody:x:99:99:Nobody:/:/sbin/nologin

# grep ^nobody /usr/lib/group
nobody:x:99:

However according to Fedora definition the entries for nobody are really expected to have UID/GID equal to 65534:

• https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/#_list_of_statically_allocated_uidgid_and_corresponding_package
• https://pagure.io/setup/blob/289bc53aa97c0758d8cf910b99f3515e21a34a40/f/passwd#_13
• https://pagure.io/setup/blob/289bc53aa97c0758d8cf910b99f3515e21a34a40/f/group#_24

PS: I spotted this while looking into #1197, but the issues are not really otherwise related.

[lucab]

The 99 IDs are coming from our hardcoded manifests:

• https://github.com/coreos/fedora-coreos-config/blob/d709e4f5fc3970fb6b938dc7bcfdb8d602d2db94/manifests/passwd#L13
• https://github.com/coreos/fedora-coreos-config/blob/d709e4f5fc3970fb6b938dc7bcfdb8d602d2db94/manifests/group#L24

The content didn't get changed since they were added in coreos/fedora-coreos-config@43c8f86, but I think those entries have a back-story somewhere else.

[runiq]

but I think those entries have a back-story somewhere else.

Appears to be a RHEL7-ism?

Edit: On second thought, probably not, since this is a tracker for Fedora (=upstream from RHEL). Sorry for the noise.

[lucab]

@runiq maybe not directly, but the link you found explains a bit more of the context and I wasn't aware of that. Thanks for bringing it up!

Relevant excerpt from that page:

• on a RHEL 7 system, the nobody user has the uid/gid 99
• the kernel uses the 65534:65534 uid/gid pair as the "overflow user id"
• defining the nobody user with the uid/pair of 65534 is not an industry standard, but it is a current good practice: multiple Linux distributions, and BSD systems follow this convention
• this changed was implemented on RHEL 8

[runiq]

The nobody user being 65534 appears to be favored by systemd, too. I mean, it kind of makes sense for the overflow UID and the nobody user to be the same number.

[travier]

It's an historical artefact: https://fedoraproject.org/wiki/Changes/RenameNobodyUser :

Changing existing systems is hard, so this change would apply only to new systems. "New" means systems which have neither the old "nobody" user with uid 99 nor the nfsnobody user defined. During package installation/upgrade a scriptlet would check if either of those two conditions is encountered, and if it is, keep current behaviour (nobody=99, nfsnobody=65534), and otherwise, define nobody=65534.

[dustymabe]

We discussed this during open floor of the community meeting today.

As @travier mentioned above the change to 65534 was done as a Fedora Change in F28. This was around the same time as the CoreOS Inc aquisition and we were not following Fedora changes closely, so we stayed with the old 99 for nobody.

In the meeting the proposal that seemed to surface was to group any effort to resolve this difference with the sysusers work that we have been wanting to do for a while. The proposal for upgrading systems was:

• migrate to sysusers
  • merge /etc & /usr before we remove /usr and then do the switch
• user nobody is still 99 (new user won't be created)
• (optional) FCOS user can run a script to update system and files to have nobody user be 65534
  • this gets them up to current standards, but is optional

[lucab]

I found another mismatched group today while doing some more work on sysusers.d groups:

$ grep ^tape /usr/lib/group
tape:x:30:

But according to Fedora GID allocation table, tape group should have ID 33: https://pagure.io/setup/blob/289bc53aa97c0758d8cf910b99f3515e21a34a40/f/group#_18.

Apparently this was a Fedora 20 bug: https://bugzilla.redhat.com/show_bug.cgi?id=1179585.
GID 30 is currently allocated to group gopher, so it would be nice to fix this mixup before creating further conflicts.

[cgwalters]

I suspect that nothing uses this and we can just fix our pinned copy.

[lucab]

I suspect that nothing uses this and we can just fix our pinned copy.

I share the same feeling.

@jlebon @travier if you are ok with that direction, I've opened coreos/fedora-coreos-config#1832 to fix it.

[travier]

coreos/fedora-coreos-config#1832 (comment)

[lucab]

One more mismatch is the sudo group:

$ grep ^sudo group
sudo:x:16:

But GID is 16 assigned to the oprofile group: https://pagure.io/setup/blob/289bc53aa97c0758d8cf910b99f3515e21a34a40/f/uidgid#_25

So far I couldn't find out where this entry is coming from, any hints will be appreciated.
I'm not in a hurry to touch this, as it may security side-effects and the oprofile package is a dead one in Fedora.

[lucab]

One more mismatch is related to the input group:

$ grep ^input group
input:x:995:

But according to Fedora GID allocation table, input group should have ID 104: https://pagure.io/setup/blob/289bc53aa97c0758d8cf910b99f3515e21a34a40/f/uidgid#_112.
This case is similar to the tape one, as the group is only used in an ephemeral way by udev rules. Thus it should be fairly safe to reconcile this entry with Fedora at once.