Red Hat Bugzilla – Bug 485379
nfsnobody gid is wrong
Last modified: 2009-07-16 03:32:29 EDT
Created attachment 331812 [details]
Patch for nfs-utils.spec
Description of problem:
nfsnobody gid is incorrect (less than 500) in /etc/passwd and /etc/group. However all_squash on exports still uses 65534 or 4294967294 (which should be correct).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. install nfs-utils, either with rpm or yum
2. grep nfsnobody /etc/passwd, observe gid
3. grep nfsnobody /etc/group, observe gid
gid is listed as something other than 65534 (32-bit) or 4294967294 (64-bit)
gid should be 65534 (32-bit) or 4294967294 (64-bit)
To expand upon the description, if you export a writable directory with the all_squash option, new files will be created with the correct gid . However, ls will display the gid numerically, because the gid is not defined as it should be.
The preinstall script in the rpm creates the nfsnobody user, but does not specify the gid. I've attached a patch for the .spec file that updates %pre. (It might not work completely for people who update from rawhide, but an install should work fine. F11 is newer than brand new, after all.)
*** Bug 455980 has been marked as a duplicate of this bug. ***
*** Bug 458242 has been marked as a duplicate of this bug. ***
I've just hit this problem where I've got a mixed network of 32-bit and 64-bit machines but they share common passwd, shadow, group and gshadow files. The 64-bit UID for nfsnobody crashes system-config-users on the 32-bit machines. Could this 64-bit entry also break other things on the 32-bit machines or am I forced to have different passwd files for the 32-bit and 64-bit systems?
Re: Comment 3
There are some users and groups that should be defined locally (like root). I'd say nfsnobody/nfsnobody is one of them, as well. The unsigned representation of -2 won't be the same on every machine, but that's what the uid and gid are suppsed to be.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.
More information and reason for this action is here:
nfs-utils-1.2.0-2.fc11 has been submitted as an update for Fedora 11.
I tested the 32-bit package (nfs-utils-1.2.0-2.fc11.i586).
I can confirm that the gid is now -2, but unfortunately both the uid and gid are the 64-bit value (4294967294) in the 32-bit package.
In the .spec file, there is the following (pre-existing) logic:
# Define the correct unsigned uid value for 32 or 64 bit archs
%define nfsnobody_uid 65534
%define nfsnobody_uid 4294967294
So somehow in the build process, all_32bit_archs isn't getting defined (or isn't getting defined as "true") for the i586 build.
I don't know if that's a bug in rpmbuild or in the options that get passed to it for this package.
I don't recall if the 64-bit value was substituted for the 32-bit value in the 32-bit package when I filed the bug originally (I'll check, though), but now *both* the uid and gid are wrong on 32-bit archs. At least they're wrong for the same reason, so it's getting closer.
I'll leave a (shorter) note in bodhi, too.
thanks for testing this out... I wonder if you completely removed
the nfs-utils package (ala yum remove nfs-utils) and then reinstall
it (ala yum install nfs-utils) would fix the problem...
Created attachment 347322 [details]
Patch against 1.2.0-2 to define i586 (and i486) as 32-bit arch
Re: Comment 7
I probably filed the bug based on the Alpha DVD, which I don't have any more.
I can't get nfs to create nfsnobody from the Beta DVD.
... but to continue debugging ...
I think I have found the next part of the problem. The spec file also contains the lines:
# group all 32bit related archs
%define all_32bit_archs i386 i686 athlon ppc sparcv9
For the i586 (and i486, for good measure) arch, it needs to be:
# group all 32bit related archs
%define all_32bit_archs i386 i486 i586 i686 athlon ppc sparcv9
When I do an rpmbuild with that additional change, I get the values I expect for the nfsnobody uid and gid in the 32-bit package.
I've attached a patch against the nfs-utils-1.2.0-2.fc11 spec file.
Re: Comment 8
Despite the difference in time, your Comment and my Comment 9 crossed paths. I did try uninstalling and reinstalling. What that does is make sure uid=gid, instead of gid < 500.
Here's the offending preinstall script from build in the i586 package currently in koji:
cat /etc/group | cut -d':' -f 3 | grep --quiet 4294967294 2>/dev/null
if [ "$?" -eq 1 ]; then
/usr/sbin/groupadd -g 4294967294 nfsnobody 2>/dev/null || :
# If UID 65534 (or 4294967294 64bit archs) is unassigned, create user "nfsnobody"
cat /etc/passwd | cut -d':' -f 3 | grep --quiet 4294967294 2>/dev/null
if [ "$?" -eq 1 ]; then
/usr/sbin/useradd -l -c "Anonymous NFS User" -r -g 4294967294 \
-s /sbin/nologin -u 4294967294 -d /var/lib/nfs nfsnobody 2>/dev/null || :
So it really is the spec that needs another quick edit.
I think the Alpha still had i386 packages. But even so, I apologize for not noticing the changed condition of the bug, although I suppose you could technically call the additional effect of i386->i586 a different bug. Would that, in fact, be preferable?
Looks good to me.
nfs-utils-1.2.0-3.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update nfs-utils'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-5985
nfs-utils-1.2.0-3.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.