Man mount says regarding permissions of the mount point: " The previous contents (if any) and owner and mode of dir become invisible, [...]" "Mount options for fat [...] umask=value [...] The default is the umask of the current process." I have a /dev/sda1, type msdos (for which fat mount options apply: "Mount options for msdos: See mount options for fat." (man mount)), and will try mounting on /mnt/stick. Let's examine umask of current process: kestrel root # umask 0022 Now let's mount without specifying umask: kestrel root # mount /dev/sda1 /mnt/stick kestrel root # ls -lad /mnt/stick drwxr--r-- 4 root root 16384 Jan 1 1970 /mnt/stick Now let's try specifying the current process umask explicitly (which shouldn't have any effect, because according to the man page, is default anyway): kestrel root # umount /dev/sda1 kestrel root # mount /dev/sda1 /mnt/stick -o umask=22 kestrel root # ls -lad /mnt/stick drwxr-xr-x 4 root root 16384 Jan 1 1970 /mnt/stick You can see, it has effect, and therefore the mount command is using incorrect default umask. Reproducible: Always Steps to Reproduce: 1. 2. 3. Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.4.20041102-r1, 2.6.11-gentoo-r5 i686) ================================================================= System uname: 2.6.11-gentoo-r5 i686 Intel(R) Pentium(R) M processor 1.50GHz Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.5 [2.3.5 (#1, May 4 2005, 16:17:52)] dev-lang/python: 2.3.5 sys-apps/sandbox: [Not Present] sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r7 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=pentium3 -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium3 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X alsa apm arts avi berkdb bitmap-fonts cdr crypt cups curl emboss encode esd fam foomaticdb fortran gdbm gif gpm gtk gtk2 guile imagemagick imap imlib ipv6 jack java jpeg kde ldap libg++ libwww mad mikmod motif mozilla mp3 mpeg mysql ncurses nls ogg oggvorbis opengl oss pam pdflib perl png python qt quicktime readline ruby samba sdl slang spell ssl svga tcltk tcpd tetex tiff tls truetype truetype-fonts type1-fonts vorbis xine xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
This is not a mount bug, but a kernel-bug. umask=nnn is passed along other user-flags to the mount syscall as a string, and the kernel-filesystem driver parses the string and denies the syscall if a syntax-error occures. Not all filesystems supports umask, so umask is not sent unless spesified. If the mount man-page claims that umask is defaulted to the current shell umask setting, the kernel-driver needs to take this into account when umask isn't found in the string it receives from user-space. Just my 5 cent about this bug
sounds convincing to me :) iirc, last time i tried using umask, ntfs suffered from similar issues ... but that was a while ago
mount bug. Attaching patch against util-linux which I will send upstream for comments.
Created attachment 64688 [details, diff] Don't set umask in mount
Patch does make sense (if the default is to use current process's umask, it should not explicitly set it to 022 ...) ... Daniel, did they get back to you?
i havent looked through the code but wouldnt the best change be to set umask(022) if the user did not specify the umask option ?
The reason it was added was to prevent the temporary files (e.g. /etc/mtab~) being writable because this can lead to the user getting a root shell. However, I went through the code, and theres only one place where theres a chance of a writable file being created, and the umask is already controlled (it sets to 022, creates file, then restores the umask). I've had no response from the upstream maintainer but just sent another email.
Adrian Bunk (upstream maintainer) replies: "sorry, this patch is still part of the big batch of util-linux emails I have to go through." I think its safe to assume this patch is valid. Please include in the ebuild.
added to 2.12q-r1
