Bug 81601 - stat(2) of files owned by uid > 64K returns bogus uid
Summary: stat(2) of files owned by uid > 64K returns bogus uid
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 2.1
Hardware: ia64 Linux
medium
medium
Target Milestone: ---
Assignee: Larry Woodman
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-01-10 23:40 UTC by Jay Fenlason
Modified: 2014-08-31 23:24 UTC (History)
1 user (show)

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

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Description Jay Fenlason 2003-01-10 23:40:01 UTC 
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
3.
    

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 13:07:54 UTC 
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.