Bug 769636 - systemd NFS Mounts Ignore "exec" Flag
Summary: systemd NFS Mounts Ignore "exec" Flag
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: util-linux
Version: 16
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Karel Zak
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-12-21 14:50 UTC by Richard Heck
Modified: 2013-01-22 19:32 UTC (History)
10 users (show)

Fixed In Version: util-linux-2.20.1-2.2.fc16
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-01-28 03:24:50 UTC


Attachments (Terms of Use)

Description Richard Heck 2011-12-21 14:50:06 UTC
, 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.

Comment 1 Michal Schmidt 2011-12-21 23:21:30 UTC
(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

Comment 2 Michal Schmidt 2011-12-21 23:46:33 UTC
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.

Comment 3 Richard Heck 2011-12-22 03:50:07 UTC
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.

Comment 4 Richard Heck 2011-12-22 03:56:24 UTC
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.

Comment 5 Karel Zak 2011-12-22 09:54:18 UTC
(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.

Comment 6 Karel Zak 2011-12-22 12:06:48 UTC
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.

Comment 7 Richard Heck 2011-12-22 15:08:36 UTC
/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

Comment 8 Richard Heck 2011-12-22 15:16:23 UTC
Removing the "user" bit fixes the problem. But it's still a mystery why it only happens when it's automounted.

Comment 9 Karel Zak 2011-12-22 15:33:31 UTC
Ah...it's possible to reproduce the problem when mounted by root (uid=0).

Comment 10 Richard Heck 2011-12-22 15:41:23 UTC
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.

Comment 11 Karel Zak 2011-12-22 16:10:36 UTC
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.

Comment 12 Richard Heck 2011-12-22 16:57:43 UTC
OK, thanks. I guess the way systemd mounts these things must have triggered this bug.

Comment 13 Karel Zak 2012-01-02 10:42:11 UTC
Fixed in upstream tree by commit a4c0cc75ff9744299f108c259efab1bd30c8007a. Fedora packages will be updated later.

Comment 14 Fedora Update System 2012-01-23 14:10:26 UTC
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

Comment 15 Fedora Update System 2012-01-23 21:52:22 UTC
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).

Comment 16 Fedora Update System 2012-01-28 03:24:50 UTC
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.

Comment 17 Leon Flaks 2013-01-22 19:32:04 UTC
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?


Note You need to log in before you can comment on or make changes to this bug.