Bug 81601 - stat(2) of files owned by uid > 64K returns bogus uid
stat(2) of files owned by uid > 64K returns bogus uid
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: kernel (Show other bugs)
ia64 Linux
medium Severity medium
: ---
: ---
Assigned To: Larry Woodman
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2003-01-10 18:40 EST by Jay Fenlason
Modified: 2014-08-31 19:24 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-28 09:07:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jay Fenlason 2003-01-10 18:40:01 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)

Description of problem:
When I created a testuser with a uid of 100000, then did an ls -la of 
~testuser, the ls showed up as being owned by nfsnobody.   AFAICT the files are 
actually owned by the testuser, but the stat(2) system call is returning an 
incorrect value in the st_uid field.  When I su to testuser, id(1) shows the 
correct uid and gid, and I can chmod the files.  When I su to nfsnobody, id(1) 
shows the same uid and gid as ls -l shows for the files, but I cannot chmod or 
access them.

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

How reproducible:
Didn't try

Steps to Reproduce:
1.useradd -u 100000 testuser
2.ls -la ~testuser

Actual Results:  Files appear to be owned by nfsnobody rather than testuser.

Expected Results:  Files should be correctly listed as owned by testuser.

Additional info:
Comment 1 Larry Woodman 2005-09-28 09:07:54 EDT
We cant make this type of change to AS2.1 any more.  Please open up a RHEL3 or
RHEL4 bug if it is a problem there.

Larry Woodman

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