On Mon, Apr 30, 2007 at 01:06:22PM -0400, Mike Frysinger wrote: > On Tuesday 24 April 2007, Karel Zak wrote: > > I don't understand what do you want to fix by this patch. Please, > > try to describe the problem. > > > > We have to overwrite the umask, because default for mount(2) is the > > umask of the current process. The mount & umount are suid and I don't > > think we want to allow non-root users to control umask for mounted > > filesystems (when umask= is not defined in fstab together with > > user/users option). > > the umask() force there breaks the umask= option in /etc/fstab ... for full > info/test case/etc... see this bug report: > http://bugs.gentoo.org/93671 > perhaps we took the wrong approach in Gentoo, but there is a bug here ;) I cannot reproduce the bug from gentoo bugzilla on FC6: # umask 022 # mount /dev/loop0 /mnt/test # ls -lad /mnt/test drwxr-xr-x 2 root root 16384 Jan 1 1970 /mnt/test # mount /dev/loop0 /mnt/test -o umask=022 /# ls -lad /mnt/test drwxr-xr-x 2 root root 16384 Jan 1 1970 /mnt/test # mount /dev/loop0 /mnt/test -o umask=0026 # ls -lad /mnt/test drwxr-x--x 2 root root 16384 Jan 1 1970 /mnt/test # mount /dev/loop0 /mnt/test -o umask=0066 # ls -lad /mnt/test drwx--x--x 2 root root 16384 Jan 1 1970 /mnt/test # mount /dev/loop0 /mnt/test -o umask=0077 # ls -lad /mnt/test drwx------ 2 root root 16384 Jan 1 1970 /mnt/test # blkid /dev/loop0 /dev/loop0: SEC_TYPE="msdos" UUID="4636-7F34" TYPE="vfat" # uname -a Linux petra 2.6.20-1.2944.fc6xen #1 SMP Tue Apr 10 18:03:37 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux > maybe need to load the umask option from user/fstab and then clear explicit > bits based on the user doing the mount ... The mount(8) is a wrong place for the bugfix (but are you really sure that you are able to reproduce the problem on a newer kernel?). Karel -- Karel Zak <kzak@xxxxxxxxxx> Red Hat Czech s.r.o. Purkynova 99/71, 612 45 Brno, Czech Republic Reg.id: CZ27690016 - To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html