Bug 147786

Summary:	Large UID not correctly supported by mkfs.ext2
Product:	Red Hat Enterprise Linux 3	Reporter:	Emilio Riva <emilio.riva>
Component:	e2fsprogs	Assignee:	Eric Sandeen <esandeen>
Status:	CLOSED ERRATA	QA Contact:	Jay Turner <jturner>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.0	CC:	sct, srevivo
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:	1.40.2-2.fc7	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-08-24 05:35:54 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:

Description Emilio Riva 2005-02-11 10:05:56 UTC

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 
mk2fs.ext2

Additional info:
none

Comment 1 Stephen Tweedie 2005-02-11 11:58:57 UTC

Reproduced on current e2fsprogs, I will look into this.

Comment 2 Eric Sandeen 2007-05-04 23:07:58 UTC

Still exists in e2fsprogs 1.39

Comment 3 Eric Sandeen 2007-05-04 23:37:08 UTC

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 17:30:07 UTC

I sent a patch upstream for this:

http://www.mail-archive.com/linux-ext4@vger.kernel.org/msg01684.html

Comment 5 Eric Sandeen 2007-05-08 15:04:14 UTC

Ted committed this change upstream:
http://thunk.org/hg/e2fsprogs/?rev/e8ee847d6992

Comment 6 Eric Sandeen 2007-07-02 21:42:28 UTC

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.

Thanks,
-Eric

Comment 7 Emilio Riva 2007-07-03 06:44:16 UTC

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 05:49:33 UTC

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 05:35:41 UTC

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.