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
Reproduced on current e2fsprogs, I will look into this.
Still exists in e2fsprogs 1.39
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.
I sent a patch upstream for this: http://www.mail-archive.com/linux-ext4@vger.kernel.org/msg01684.html
Ted committed this change upstream: http://thunk.org/hg/e2fsprogs/?rev/e8ee847d6992
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
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!
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.
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.