Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionPierguido Lambri
2017-04-19 13:56:57 UTC
Description of problem:
When mounting a NFS share with the option 'user' from fstab, as per man page the options noexec, nosuid, and nodev should be applied.
If it's mounted from root, it works. If it's done from a normal user it doesn't set these options (allowing the user to execute programs from the share)
Version-Release number of selected component (if applicable):
nfs-utils-1.2.3-75.el6.x86_64
How reproducible:
Always
Steps to Reproduce:
1. Set a fstab entry as:
192.168.122.10:/exports /mnt nfs defaults,noauto,user 0 0
2. Mount it via normal user
Actual results:
$ nfsstat -m
/mnt from 192.168.122.10:/exports/
Flags: rw,relatime,vers=4,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.122.11,minorversion=0,local_lock=none,addr=192.168.122.10
Expected results:
$ nfsstat -m
/mnt from 192.168.122.10:/exports/
Flags: rw,nosuid,nodev,noexec,relatime,vers=4,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.122.11,minorversion=0,local_lock=none,addr=192.168.122.10
Additional info:
RHEL7 works fine
I can still reproduce it with the latest nfs-utils:
RHEL6:
$ uname -r
2.6.32-696.16.1.el6.x86_64
$ rpm -qa | grep nfs-utils
nfs-utils-1.2.3-75.el6_9.x86_64
nfs-utils-lib-1.1.5-13.el6.x86_64
$ nfsstat -m
/mnt from 192.168.122.10:/exports/
Flags: rw,relatime,vers=4,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.122.12,minorversion=0,local_lock=none,addr=192.168.122.10
$ ls -l /mnt/ls
-rwxr-xr-x. 1 test test 117048 Dec 13 2017 /mnt/ls
$ /mnt/ls -l
total 0
-rw-rw-r--. 1 test test 0 Dec 13 10:28 test1
-rw-rw-r--. 1 test test 0 Dec 13 10:28 test2
-rw-rw-r--. 1 test test 0 Dec 13 10:28 test3
-rw-rw-r--. 1 test test 0 Dec 13 10:28 test4
-rw-rw-r--. 1 test test 0 Dec 13 10:28 test5
RHEL7:
$ whoami
test
$ nfsstat -m
/mnt from 192.168.122.10:/exports
Flags: rw,nosuid,nodev,noexec,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.122.35,local_lock=none,addr=192.168.122.10
$ /mnt/ls -l
-bash: /mnt/ls: Permission denied
Comment 10Steve Whitehouse
2018-02-01 10:06:09 UTC
This looks like something we should try to resolve for 6.10, since there are security implications.
Steve D, is the info in comment #9 enough for you to reproduce this?
Created attachment 1417811[details]
proposed patch
It looks like libmount is shipped as part of util-linux-ng in rhel6. I don't see a libmount-devel or a util-linux-ng-devel package, nor do a see a package providing libmount.h. It would be quite a bit of churn pulling in the libmount support in nfs-utils just so we get the correct flags on user mounts. So I suggest we just use the attached rhel6-only patch instead.
That patch looks to fix it.
The mount command adds in the noexec,nosuid,noauto opts and hands them to mount.nfs which then discards them as untrusted and takes the unedited flags from fstab instead. The latest nfs-utils appears to still do this, but i assume the flags get fixed up by some later mechanism.
(In reply to Scott Mayhew from comment #15)
> Created attachment 1417811[details]
> proposed patch
Got it... Thanks!
>
> It looks like libmount is shipped as part of util-linux-ng in rhel6. I
> don't see a libmount-devel or a util-linux-ng-devel package, nor do a see a
> package providing libmount.h. It would be quite a bit of churn pulling in
> the libmount support in nfs-utils just so we get the correct flags on user
> mounts. So I suggest we just use the attached rhel6-only patch instead.
I agree...
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2018:1855