Bug 144816

Summary: ls -l on a nfs mount filesystem should show user and group id as nfsnobody instead of 4294967294
Product: Red Hat Enterprise Linux 2.1 Reporter: John Poelstra <poelstra>
Component: nfs-utilsAssignee: Steve Dickson <steved>
Status: CLOSED CURRENTRELEASE QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 2.1   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: nfs-utils-0.3.3-11 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-09-06 11:35:36 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
output of rpm -vv none

Description John Poelstra 2005-01-11 18:48:41 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
ls -l on a nfs mount filesystem should show user and group id as
nfsnobody instead of 4294967294

A review of the the install (rpm -vv) shows that the wrong UID is
being assigned to nfsnobody.

This is the bad line....
/usr/sbin/useradd -c 'Anonymous NFS User' -r -s /sbin/nologin -u 65534
-d /var/lib/nfs nfsnobody 

I will attach the entire output.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Install current nfs-utils package
2.
3.
    

Actual Results:  user and group for nfsnobody are shown as 4294967294

Expected Results:  ls -l on a nfs mount filesystem should show user
and group id as nfsnobody instead of 4294967294

Additional info:

Comment 1 John Poelstra 2005-01-11 18:50:34 UTC
Created attachment 109629 [details]
output of rpm -vv

Comment 2 Steve Bonneville 2005-07-14 12:14:15 UTC
This issue also applies to RHEL4, and possibly all other recent releases.  The
nfsnobody user and group are set to UID/GID -2, which is now 4294967294, not
65535.  THIS IS NOT ONLY A 64-BIT ARCHITECTURE PROBLEM, it occurs because the
UID/GID space was extended from 16 bits to 32 bits, and therefore it does occur
on the 32-bit x86 version of the distribution. 

To verify this, create a export a NFS filesystem read-write which includes
a world-writable test directory, mount it from a client, and on that client
have root touch a file in the test directory.  Then look at the ownerships
on that file.

Do I need to open a separate RHEL4 version of this bug?