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.
Bug 1594707 - nfs-utils-1.2.3-78.el6 enforces noexec even when it should not
Summary: nfs-utils-1.2.3-78.el6 enforces noexec even when it should not
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: nfs-utils
Version: 6.10
Hardware: Unspecified
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Steve Dickson
QA Contact: Yongcheng Yang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-06-25 09:08 UTC by manuel wolfshant
Modified: 2022-03-13 15:09 UTC (History)
13 users (show)

Fixed In Version: nfs-utils-1.2.3-78.el6_10.1
Doc Type: If docs needed, set a value
Doc Text:
Previously, NFS did not allow you to override the "noexec", "nosuid", and "nodev" options, which are automatically added for NFS shares mounted with the "users" option. With this update, specifying the "exec", "suid", or "dev" options in the /etc/fstab file now correctly overrides the default options. As a result, the described problem no longer occurs.
Clone Of:
Environment:
Last Closed: 2018-10-09 15:49:30 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Move where the secure options are added (1.25 KB, patch)
2018-06-26 16:07 UTC, Alice Mitchell 		no flags Details | Diff
The need patch... all that's needed now is the PM acks (1.26 KB, patch)
2018-08-08 14:27 UTC, Steve Dickson 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1443579 0 high CLOSED NFS user mounts do not enforce 'noexec' 2021-09-09 12:15:37 UTC
Red Hat Knowledge Base (Solution) 3547051 0 None None None 2018-08-22 14:36:07 UTC
Red Hat Product Errata RHBA-2018:2896 0 None None None 2018-10-09 15:49:36 UTC

Internal Links: 1443579

Description manuel wolfshant 2018-06-25 09:08:06 UTC 
Description of problem:
Since updating to nfs-utils-1.2.3-78.el6, the combination "users, exec" in fstab is ignored and mount is always noexec, even when done manually by root

Version-Release number of selected component (if applicable):
nfs-utils-1.2.3-78.el6

How reproducible:
always

Steps to Reproduce:
1. update to nfs-utils-1.2.3-78.el6
2. use in fstab a line similar to
apps:/apps           /apps                   nfs     defaults,ro,users,exec,auto       0 0
3. reboot or remount

Actual results:
apps:/apps on /apps type nfs (ro,users,noexec,nosuid,nodev)     

Expected results: 
apps:/apps on /apps type nfs (ro,users,nosuid,nodev)        

Additional info:
Downgrading to nfs-utils-1.2.3-75.el6_9 fixes the issue.

I am familiar with https://bugzilla.redhat.com/show_bug.cgi?id=1443579 but from my point of view the fix was implemented incorrectly as now the remote share cannot be mounted exec even by root if 'users,exec" is present in fstab. A mount -o remount,exec leads always to a noexec result.
Comment 2 Alice Mitchell 2018-06-26 16:07:37 UTC 
Created attachment 1454710 [details]
Move where the secure options are added

Yes, the previous patch is a little too broad in when it applies the necessary mount options and as a consequence ends up overriding legitimate options.

See my attached patch which replaces the previous patch with a different approach, which still adds in the necessary options when a user mount is made, but does so in a way which can be overridden by root and by fstab entries. Which afaics addresses both this and bug 1443579
Comment 10 Steve Dickson 2018-08-08 14:27:33 UTC 
Created attachment 1474356 [details]
The need patch... all that's needed now is the PM acks
Comment 26 Yongcheng Yang 2018-08-23 08:21:46 UTC 
Moving to VERIFIED according to test logs of comment #25
Comment 30 yuk 2018-09-25 12:14:12 UTC 
Is the fix available for RHEL 6 ?

I still can't find nfs-utils-1.2.3-78.el6_10.1.
Comment 31 manuel wolfshant 2018-09-25 20:12:27 UTC 
https://access.redhat.com/solutions/3547051 mentions that the corrected package will be included in the next minor release of RHEL
Comment 32 yuk 2018-09-26 09:59:41 UTC 
I'll open a case.
I can't wait for RHEL 6.11 for a small but fundamental fix.
Comment 33 Yongcheng Yang 2018-09-26 10:17:55 UTC 
(In reply to yuk from comment #30)
> Is the fix available for RHEL 6 ?
> 
> I still can't find nfs-utils-1.2.3-78.el6_10.1.

Hi yuk, thanks for your attention.

I don't know the exact date when the package is available publicly.
However, as usual, it should not be too long.

Please keep noticing this bug until its status turns to be "CLOSE". Thanks!
Comment 34 Marek Suchánek 2018-09-27 11:06:23 UTC 
Hello Justin, would this be a correct description of the bug fix?

> Previously, NFS ignored the "exec" mount option, and always mounted NFS 
> shares with "noexec" instead. As a consequence, it was not possible to 
> execute binaries on the mounted share. With this update, NFS now 
> recognizes the "exec" option in the /etc/fstab file and in mount 
> commands used by the root user. As a result, the described problem no 
> longer occurs.

Thanks,
Marek
Comment 35 Alice Mitchell 2018-09-27 11:40:44 UTC 
Not really no, noexec has existed as an option for a long time, this does not change that.

When mounts have the 'users' option set in fstab, it permits non-root users to mount and unmount them, but the noexec, nosuid, and nodev options are automatically added to the default options list as a security precaution. This can be overridden by the system administrator specifically specifying their opposites in the fstab entry.

The bug caused this fstab override to be ignored, causing the default options to always be set when users was used, regardless of the specified overrides.
Comment 36 Marek Suchánek 2018-09-27 14:00:17 UTC 
(In reply to Justin Mitchell from comment #35)
> Not really no, noexec has existed as an option for a long time, this does
> not change that.
> 
> When mounts have the 'users' option set in fstab, it permits non-root users
> to mount and unmount them, but the noexec, nosuid, and nodev options are
> automatically added to the default options list as a security precaution.
> This can be overridden by the system administrator specifically specifying
> their opposites in the fstab entry.
> 
> The bug caused this fstab override to be ignored, causing the default
> options to always be set when users was used, regardless of the specified
> overrides.

Thanks for the clarification.

I've edited my description:

> Previously, NFS did not allow you to override the "noexec", 
> "nosuid", and "nodev" options, which are automatically added for 
> NFS shares mounted with the "users" option. With this update, 
> specifying the "exec", "suid", or "dev" options in the /etc/fstab 
> file now correctly overrides the default options. As a result, 
> the described problem no longer occurs.

If can be improved further, please let me know.
Comment 38 errata-xmlrpc 2018-10-09 15:49:30 UTC 
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:2896
Note You need to log in before you can comment on or make changes to this bug.