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.
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.
Descriptionmanuel 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.
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
(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!
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
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.
(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.
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