, which is on an NFS mount, with ~/bin/ being a soft link to ~/files/bI have a directory files/ under my homein/. With F16, I can't execute these files (and I can't execute them with the full path name, either, so it's not the link or any such thing). The really strange this is that I *can* execute them if I unmount this directory, which is automatically mounted at boot time, and then remount it manually. So it appears that the mounting process started by systemd is ignoring the "exec" flag. My /etc/fstab reads (in the relevant part): 192.168.1.1:/home/rgheck/files/ /home/rgheck/files nfs auto,user,rw,dev,nosuid,exec,_netdev 0 0 But I end up with: 192.168.1.1:/home/rgheck/files/ on /home/rgheck/files type nfs (rw,nosuid,nodev,noexec,relatime,vers=3,rsize=32768,wsize=32768,namlen=255, hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.1,mountvers=3, mountport=843,mountproto=udp,local_lock=none,addr=192.168.1.1,_netdev) with noexec instead.
(In reply to comment #0) > The really strange this is that I *can* execute them if I unmount > this directory, which is automatically mounted at boot time, and then remount > it manually. Using what command exactly? > So it appears that the mounting process started by systemd is > ignoring the "exec" flag. That's weird, because systemd just spawns /bin/mount $mountpoint
I can reproduce the bug using this line in /etc/fstab: 192.168.1.2:/multimedia /mnt nfs user,exec 0 0 After "mount /mnt" /proc/self/mountinfo shows: 46 23 0:39 / /mnt rw,nosuid,nodev,noexec,relatime shared:2 - nfs4 192.168.1.2:/multimedia/ rw,vers=4,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.122.145,minorversion=0,local_lock=none,addr=192.168.1.2 man mount says this about the 'user' option: This option implies the options noexec, nosuid, and nodev (unless overridden by subsequent options, as in option line user,exec,dev,suid). In the testcase there is the subsequent 'exec' option, but it seems to be ignored. strace shows: 3034 execve("/bin/mount", ["mount", "/mnt"], [/* 23 vars */]) = 0 ... 3035 execve("/sbin/mount.nfs", ["/sbin/mount.nfs", "192.168.1.2:/multimedia", "/mnt", "-o", "rw,nosuid,nodev,user"], [/* 19 vars */]) = 0 ... 3035 mount("192.168.1.2:/multimedia", "/mnt", "nfs", MS_NOSUID|MS_NODEV|MS_NOEXEC, "vers=4,addr=192.168.1.2,clientad"...) = 0 Notice that "exec" is missing in the arguments to mount.nfs. I think it's a bug in /bin/mount. Reassigning to util-linux.
I suppose this could be a bug in /bin/mount. But I've just done this (which also answers the first question): > sudo umount /home/rgheck/files > mount /home/rgheck/files and now I can execute stuff there. So /bin/mount seems fine. (And this worked just as it should with F14.) I wonder if there's a connection here with the fact that I was having problems earlier with very long boot times. I was getting a 60 second delay at boot due, it would seem, to an inability to mount these directories, since (I assume) the network was not available at boot time (hence a 60 second timeout). I've since resolved that via the "noauto,comment=systemd.automount" trick, so maybe it's not just /bin/mount that is involved? Please note: The problem exists both with and without the comment trick, but I'd assume that, without it, the directory has to be mounted later, too.
So one more datapoint, which suggests maybe it is an automount issue. If I do: > sudo umount /home/rgheck/files > ls /home/rgheck/files so that the directory gets automounted again, I cannot execute files there. If, on the other hand, I do: > mount /home/rgheck/files then I can execute files there. If it's relevant, this is an NFS3 share. The server is running Centos 5.x.
(In reply to comment #2) > 3035 execve("/sbin/mount.nfs", ["/sbin/mount.nfs", "192.168.1.2:/multimedia", > "/mnt", "-o", "rw,nosuid,nodev,user"], [/* 19 vars */]) = 0 > ... > 3035 mount("192.168.1.2:/multimedia", "/mnt", "nfs", > MS_NOSUID|MS_NODEV|MS_NOEXEC, "vers=4,addr=192.168.1.2,clientad"...) = 0 > > Notice that "exec" is missing in the arguments to mount.nfs. This is irrelevant, mount.nfs is suid and cannot apply mount options from command line, otherwise users will be able to control flags for mount(2) syscall. mount.nfs reads the options from /etc/fstab > I think it's a bug in /bin/mount. Reassigning to util-linux. Probably yes, but in libmount which is used by mount.nfs to evaluate the options.
Hmm... I'm not able to reproduce this problem. $ rpm -qf /sbin/mount.nfs /lib64/libmount.so.1 nfs-utils-1.2.5-3.fc16.x86_64 libmount-2.20.1-2.1.fc16.x86_64 $ findmnt --fstab /mnt/store TARGET SOURCE FSTYPE OPTIONS /mnt/store sr.net.home:/mnt/store nfs user,exec $ mount /mnt/store $ findmnt --kernel -o VFS-OPTIONS /mnt/store VFS-OPTIONS rw,nosuid,nodev,relatime Note that the util-linux release 2.19 had a problem with user mount option evaluation, but this problem should be fixed now.
/home/rgheck/ > rpm -qf /sbin/mount.nfs /lib64/libmount.so.1 nfs-utils-1.2.5-3.fc16.x86_64 libmount-2.20.1-2.1.fc16.x86_64 /home/rgheck/ > findmnt --fstab /home/rgheck/files/ TARGET SOURCE FSTYPE OPTIONS /home/rgheck/files 192.168.1.1:/home/rgheck/files/ nfs noauto,user,rw,dev,nosuid,exec,_netdev,comment=systemd.automount /home/rgheck/ > findmnt --kernel -o VFS-OPTIONS /home/rgheck/files/ VFS-OPTIONS rw,relatime rw,nosuid,nodev,noexec,relatime
Removing the "user" bit fixes the problem. But it's still a mystery why it only happens when it's automounted.
Ah...it's possible to reproduce the problem when mounted by root (uid=0).
Confirmed. If I put the "user" flag back, then I get the problem even when I mount the directory manually...as root. If I mount it manually as a normal user, then no problem. So it's the combination of the "user" flag and the NFS share's being mounted by root that is the problem. In that case, "exec" is ignored.
Congratulation, you found pretty old bug (~ year 2001, util-linux 2.11) :-) The problem is that "exec" only inverts MS_NOEXEC from "user", and then the info about the "exec" option is lost. So when mount(8) generates command line for the mount helper (e.g. mount.nfs) then there is no information about the "exec" option. And mount.nfs uses the options (rather than original options from fstab) because it's executed by non-root user. I'll fix it ASAP, as workaround you should remove the option "user" from fstab if you want to mount the filesystem by automounter.
OK, thanks. I guess the way systemd mounts these things must have triggered this bug.
Fixed in upstream tree by commit a4c0cc75ff9744299f108c259efab1bd30c8007a. Fedora packages will be updated later.
util-linux-2.20.1-2.2.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/util-linux-2.20.1-2.2.fc16
Package util-linux-2.20.1-2.2.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing util-linux-2.20.1-2.2.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-0815/util-linux-2.20.1-2.2.fc16 then log in and leave karma (feedback).
util-linux-2.20.1-2.2.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
I just tried this issue on fedora 18. util-lunux-2.22.1-2.4.fc18.x86_64 and it seems that it is broken (again?) I have to admit - I never tried 2.20 on f-16. Should we re-open this bug?