Bug 1488897 - [nfs-utils] create group and user nfsnobody fail when install nfs-utils
Summary: [nfs-utils] create group and user nfsnobody fail when install nfs-utils
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: nfs-utils
Version: 27
Hardware: All
OS: Linux
urgent
urgent
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-09-06 12:33 UTC by JianHong Yin
Modified: 2018-05-19 21:24 UTC (History)
9 users (show)

Fixed In Version: nfs-utils-2.3.1-9.rc1.fc28
Clone Of:
Environment:
Last Closed: 2018-05-19 21:24:22 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1537262 0 unspecified CLOSED Rename "nobody" user 2021-02-22 00:41:40 UTC

Internal Links: 1537262

Description JianHong Yin 2017-09-06 12:33:05 UTC
Description of problem:

there's no user nfsnobody after install nfs-utils

Version-Release number of selected component (if applicable):
Fedora-26
latest Fedora-rawhide

How reproducible:
always

Steps to Reproduce:
1. yum install -y nfs-utils
2. id nfsnobody

Actual results:
[yjh@Fedora-26 ~]$ id nfsnobody
id: "nfsnobody": no such user

Expected results:
[yjh@fs-qe ~]$ id nfsnobody
uid=65534(nfsnobody) gid=65534(nfsnobody) groups=65534(nfsnobody)

Additional info:

Comment 1 JianHong Yin 2017-09-06 12:37:34 UTC
[yjh@Fedora-26 ~]$ rpm -q --scripts nfs-utils | grep nfsnobody
# Using the 16-bit value of -2 for the nfsnobody uid and gid
# Create nfsnobody gid as long as it does not already exist
cat /etc/group | cut -d':' -f 1 | grep --quiet nfsnobody 2>/dev/null
    /usr/sbin/groupadd -g 65534 nfsnobody >/dev/null 2>&1 || :
    /usr/sbin/groupmod -g 65534 nfsnobody >/dev/null 2>&1 || :
# Create nfsnobody uid as long as it does not already exist.
cat /etc/passwd | cut -d':' -f 1 | grep --quiet nfsnobody 2>/dev/null
                -s /sbin/nologin -u 65534 -d /var/lib/nfs nfsnobody >/dev/null 2>&1 || :
   /usr/sbin/usermod -u 65534 -g 65534 nfsnobody >/dev/null 2>&1 || :

[yjh@Fedora-26 ~]$ sudo /usr/sbin/groupadd -g 65534 nfsnobody
groupadd: GID '65534' already exists
[yjh@Fedora-26 ~]$ sudo /usr/sbin/groupadd -g 65534 nfsnobody
groupadd: GID '65534' already exists
[yjh@Fedora-26 ~]$ id 65534
uid=65534(nobody) gid=65534(nobody) groups=65534(nobody)
^^^^^^ what !?
[yjh@Fedora-26 ~]$ grep nobody /etc/group
nobody:x:99:
^^^^^^ what !?
[yjh@Fedora-26 ~]$ grep nobody /etc/passwd
nobody:x:99:99:Nobody:/:/sbin/nologin

Comment 2 JianHong Yin 2017-09-06 12:44:20 UTC
according Comment 1, this is not bug of Component nfs-utils
 but which one should I change to?

Comment 3 Steve Dickson 2017-09-06 15:55:47 UTC
(In reply to Yin.JianHong from comment #2)
> according Comment 1, this is not bug of Component nfs-utils
>  but which one should I change to?

What is in /etc/shadow ?

Comment 4 JianHong Yin 2017-09-07 02:15:15 UTC
(In reply to Steve Dickson from comment #3)
> (In reply to Yin.JianHong from comment #2)
> > according Comment 1, this is not bug of Component nfs-utils
> >  but which one should I change to?
> 
> What is in /etc/shadow ?

[yjh@dhcp-12-238 ~]$ sudo grep nfsnobody /etc/shadow
[yjh@dhcp-12-238 ~]$ sudo grep nobody /etc/shadow
nobody:*:17206:0:99999:7:::

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

Comment 6 Steve Dickson 2018-04-06 17:00:00 UTC
I can not seem to reproduce this.... Here is what I did.. 

f28# dnf remove nfs-utils

f28# grep nfsnobody /etc/passwd /etc/group
/etc/passwd:nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin
/etc/group:nfsnobody:x:65534:


f28# userdel nfsnobody
f28# grep nfsnobody /etc/passwd /etc/group
f28# dnf install nfs-utils

f28# grep nfsnobody /etc/passwd /etc/group
/etc/passwd:nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin
/etc/group:nfsnobody:x:65534:

Comment 7 Tim Niemueller 2018-04-10 11:06:14 UTC
I'm seeing the same even when just issuing the group add:

# groupadd -g 65534 nfsnobody
groupadd: GID '65534' already exists

# grep nfsnobody /etc/group
# grep nfsnobody /etc/shadow
# grep 65534 /etc/group
# grep 65535 /etc/shadow

This is on a fresh F27 server install. I installed the nfs-utils package (via ansible). User not installed. Uninstall package. Try to create user manually. Error as above. Since F27 is still supported re-opening.

Comment 8 Steve Dickson 2018-04-10 13:07:04 UTC
(In reply to Tim Niemueller from comment #7)
> I'm seeing the same even when just issuing the group add:
> 
> # groupadd -g 65534 nfsnobody
> groupadd: GID '65534' already exists
> 
> # grep nfsnobody /etc/group
> # grep nfsnobody /etc/shadow
> # grep 65534 /etc/group
> # grep 65535 /etc/shadow
> 
> This is on a fresh F27 server install. I installed the nfs-utils package
> (via ansible). User not installed. Uninstall package. Try to create user
> manually. Error as above. Since F27 is still supported re-opening.

How is this an nfs-utils problem? If groupadd says the group 
exists and it does not.... nfs-utils problem???

Comment 9 Tim Niemueller 2018-04-10 13:07:50 UTC
It's not the cause, but it seems to suffer from the same problem. It does not create the nfsnobody user which it should.

Comment 10 Zbigniew Jędrzejewski-Szmek 2018-05-15 05:45:20 UTC
The result depends on the order of operations. New setup rpms (F28+) will try to create 'nobody', but only if the name or uid are not taken yet. nfs-utils will try to create 'nfsnobody', again only if the name and uid are not taken. So the  steps in https://bugzilla.redhat.com/show_bug.cgi?id=1488897#c6 recreate 'nfsnobody' because there is no "interference" from setup.

This bug report is about nfsnobody not existing, but this is not a bug. This user should not exist anymore. I'll file a PR to make that part of the nfs-utils scriptlets clearer.

Comment 12 Tim Niemueller 2018-05-15 08:07:38 UTC
Please note that this specific bug was reported against F27 for which nfsnobody should be created.

Comment 13 Zbigniew Jędrzejewski-Szmek 2018-05-15 08:59:49 UTC
Oh, on F27 systemd's nss-systemd might generate the user on the fly. This is also OK.

Comment 14 Tim Niemueller 2018-05-15 09:08:33 UTC
No, it didn't. We needed the user only for the mapping from a container and it did not exist. And, as mentioned, we could not even create it with useradd. We ended up patching /etc/passwd with ansible.

Comment 15 Zbigniew Jędrzejewski-Szmek 2018-05-15 09:12:08 UTC
Actually you didn't ever explain why you need the user. Everything should work fine without the user defined in /etc/passwd.

Comment 16 Tim Niemueller 2018-05-15 09:16:40 UTC
We needed it to change permissions of files/directories from the container (to pre-layout the filesystem before we pass it to the container). On a second thought, we could simply have used the numeric IDs. But that seems odd. In any case, we do have a working solution for our case and once we upgrade it'll be fixed anyway (and I like the new way better).

I'm still curious why the user was rejected to be created even though it did not exist. Which component actually blocks this?

Comment 17 Zbigniew Jędrzejewski-Szmek 2018-05-15 11:25:20 UTC
> In any case, we do have a working solution
I'm glad to hear that ;)

> why the user was rejected to be created even though it did not exist.
It exists. It's just not provided by nss-files but by nss-systemd instead.

Comment 18 Zbigniew Jędrzejewski-Szmek 2018-05-15 11:29:14 UTC
... or at least I assume it exists based on the error message above. 'getent passwd 65534` should confirm that.

Comment 19 Steve Dickson 2018-05-15 13:32:43 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #11)
> https://src.fedoraproject.org/rpms/nfs-utils/pull-request/5
> https://src.fedoraproject.org/rpms/nfs-utils/pull-request/6

Why is the creation of the group being removed in these
pull-requests?

Comment 20 Zbigniew Jędrzejewski-Szmek 2018-05-15 14:00:17 UTC
It's not. Just the usermod/groupmod call to modify an existing user or group are removed. I removed them because they are only useful for upgrading from very old systems that have this user or group defined with some different number. In general Fedora only supports upgrades from two-three releases ago, and an existing user/group with different number seems like a very fringe case anyway. After the update, the scriptlets support the three realistic cases cleanly: an upgraded system with nobody=99,nfsnobody=undefined, nobody=99,nfsnobody=65534, nobody=65534,nfsnobody=undefined.

Comment 21 Steve Dickson 2018-05-15 17:38:16 UTC
Also what is the difference between %global and %define?

Comment 23 Fedora Update System 2018-05-16 12:47:39 UTC
nfs-utils-2.3.1-9.rc1.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-15092082d7

Comment 24 Fedora Update System 2018-05-17 15:26:47 UTC
nfs-utils-2.3.1-9.rc1.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-15092082d7

Comment 25 Fedora Update System 2018-05-19 21:24:22 UTC
nfs-utils-2.3.1-9.rc1.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.


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