Bug 147786 - Large UID not correctly supported by mkfs.ext2
Large UID not correctly supported by mkfs.ext2
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: e2fsprogs (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Eric Sandeen
Jay Turner
Depends On:
  Show dependency treegraph
Reported: 2005-02-11 05:05 EST by Emilio Riva
Modified: 2015-01-07 19:09 EST (History)
2 users (show)

See Also:
Fixed In Version: 1.40.2-2.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-08-24 01:35: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 Emilio Riva 2005-02-11 05:05:56 EST
Description of problem:
Wrong UID assignment when formatting a (loop) volume and UID is 
a "large" one, e.g. 501666

Version-Release number of selected component (if applicable):
e2fsprogs-1.32-15 (RedHat Enterprise 3 Server/Professional)

How reproducible:
always with large UIDs

Steps to Reproduce:
1. dd if=/dev/zero of=imgname bs=512 count=16384
2. /sbin/mkfs.ext2 -F -m 0 imgname
3. sudo mount -o loop imgname ./mnt

NB: mount enabled to this user via /etc/sudoers

Actual results:
If userID is > 32767, e.g.501666, the (loop) file system mounted 
in ./mnt is readonly for the user, because it's owned by an 
unexistent user id (42914 if UID is 501666).
If userID < 32767 all works fine and the mounted (loop) file system 
is owned by the correct user.

Expected results:
UID > 32767 should be correctly managed also from tools like 

Additional info:
Comment 1 Stephen Tweedie 2005-02-11 06:58:57 EST
Reproduced on current e2fsprogs, I will look into this.
Comment 2 Eric Sandeen 2007-05-04 19:07:58 EDT
Still exists in e2fsprogs 1.39
Comment 3 Eric Sandeen 2007-05-04 19:37:08 EDT
Something simple like this in create_root_dir fixes it up:

+               uid = getuid();
+               inode.i_uid = uid;
+               inode.i_uid_high = uid >> 16;

and similar for guid...

[root@neon tmp]# ls -lan  /mnt/tmp/
total 13
drwxr-xr-x 3 501666 501666  1024 May  4 18:32 .
drwxr-xr-x 4      0      0    28 Jan 23 10:34 ..
drwx------ 2      0      0 12288 May  4 18:32 lost+found

but, lo and behold, debugfs is confused too:

[root@neon tmp]# debugfs testfile 
debugfs 1.39 (29-May-2006)
debugfs:  stat .
Inode: 2   Type: directory    Mode:  0755   Flags: 0x0   Generation: 0
User: 42914   Group: 42914   Size: 1024
File ACL: 0    Directory ACL: 0

so looks like uid/gid handling could stand to be audited a bit here.
Comment 4 Eric Sandeen 2007-05-07 13:30:07 EDT
I sent a patch upstream for this:

Comment 5 Eric Sandeen 2007-05-08 11:04:14 EDT
Ted committed this change upstream:
Comment 6 Eric Sandeen 2007-07-02 17:42:28 EDT
For the reporter:  is this problem still an issue for you in RHEL4 or 5?  (I
know the problem exists there; I just don't know if anyone has the requirement
in rhel4/5)  It should get picked up soon in Fedora when I rebase to 1.40.

Comment 7 Emilio Riva 2007-07-03 02:44:16 EDT
The problem is currently avoided with an ad hoc script executed via 'sudo' from
authorized users, so we can say that's not a true issue on RHEL4 or 5... at
least, for us!
Comment 8 Fedora Update System 2007-07-27 01:49:33 EDT
e2fsprogs-1.40.2-2.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.
Comment 9 Fedora Update System 2007-08-24 01:35:41 EDT
e2fsprogs-1.40.2-2.fc7 has been pushed to the Fedora 7 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.