Bug 1297182 - Mounting with "-o noatime" or "-o noexec" causes "nosuid,nodev" to be set as well
Mounting with "-o noatime" or "-o noexec" causes "nosuid,nodev" to be set as ...
Status: CLOSED CURRENTRELEASE
Product: GlusterFS
Classification: Community
Component: fuse (Show other bugs)
mainline
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Karthik U S
: Triaged
Depends On: 1294809
Blocks: 1297183 1297184
  Show dependency treegraph
 
Reported: 2016-01-10 06:27 EST by Niels de Vos
Modified: 2017-05-30 14:32 EDT (History)
6 users (show)

See Also:
Fixed In Version: glusterfs-3.11.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1297183 1297184 (view as bug list)
Environment:
Last Closed: 2017-03-06 12:20:01 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Niels de Vos 2016-01-10 06:27:00 EST
Description of problem:
With additional tests after fixing bug 1296992 I noticed that mounting with "-o noatime" or "-o noexec" the additional "nosuid,nodev" mount options are set as well.

Mounting without any options does not add "nosuid,nodev"

Version-Release number of selected component (if applicable):
mainline and branches with backport of bug 1296992

How reproducible:
100%

Steps to Reproduce:
1. mount a Gluster volume with "-o noatime" or "-o noexec"
2. compare mount options in /proc/mounts

Actual results:
The "nosuid,nodev" mount options are automatically added, even when not specified in the mount command.

Expected results:
Mounting with additional options should only add/change those options, not automatically add others.

Additional info:
This most likely is caused by the flag handling in do_mount() in contrib/fuse-util/fusermount.c. Needs some investigation on the reasoning behind this.
Comment 1 Niels de Vos 2016-01-10 06:29:38 EST
Oop, bug 1294809 is the one that makes it possible again to mount with "-o noatime" and the like.
Comment 2 Csaba Henk 2016-10-27 12:05:40 EDT
See my comment on http://review.gluster.org/15730 regarding the background and purpose of the nosuid,nodev flags.

What seems to be the case is that with no{atime,exec} glusterfs mounting falls back to the unprivileged mount logic (mounting via setuid helper binary). We should investigate why this fallback happens and if possible, amend the code to go for the privileged mount logic (direct mount(2) call).

The flags, essential to the unprivileged case, should remain in place.
Comment 3 Worker Ant 2016-11-02 05:03:40 EDT
REVIEW: http://review.gluster.org/15766 (fuse: limit fusermount fallback to EPERM cases) posted (#1) for review on master by Csaba Henk (csaba@redhat.com)
Comment 4 Worker Ant 2016-11-03 02:51:21 EDT
REVIEW: http://review.gluster.org/15766 (fuse: limit fusermount fallback to EPERM cases) posted (#2) for review on master by Csaba Henk (csaba@redhat.com)
Comment 5 Worker Ant 2017-01-03 00:52:42 EST
REVIEW: http://review.gluster.org/15766 (fuse: limit fusermount fallback to EPERM cases) posted (#3) for review on master by Csaba Henk (csaba@redhat.com)
Comment 6 Worker Ant 2017-01-03 00:52:45 EST
REVIEW: http://review.gluster.org/16313 (fuse: clean up mount flag processing) posted (#1) for review on master by Csaba Henk (csaba@redhat.com)
Comment 7 Worker Ant 2017-01-03 00:57:11 EST
REVIEW: http://review.gluster.org/15766 (fuse: limit fusermount fallback to EPERM cases) posted (#4) for review on master by Csaba Henk (csaba@redhat.com)
Comment 8 Worker Ant 2017-01-03 00:57:15 EST
REVIEW: http://review.gluster.org/16313 (fuse: clean up mount flag processing) posted (#2) for review on master by Csaba Henk (csaba@redhat.com)
Comment 9 Worker Ant 2017-01-03 04:15:43 EST
REVIEW: http://review.gluster.org/16313 (fuse: clean up mount flag processing) posted (#3) for review on master by Csaba Henk (csaba@redhat.com)
Comment 10 Worker Ant 2017-01-03 09:31:32 EST
REVIEW: http://review.gluster.org/15766 (fuse: limit fusermount fallback to EPERM cases) posted (#5) for review on master by Csaba Henk (csaba@redhat.com)
Comment 11 Worker Ant 2017-01-03 09:31:36 EST
REVIEW: http://review.gluster.org/16313 (fuse: clean up mount flag processing) posted (#4) for review on master by Csaba Henk (csaba@redhat.com)
Comment 12 Worker Ant 2017-01-03 09:35:25 EST
REVIEW: http://review.gluster.org/16313 (fuse: clean up mount flag processing) posted (#5) for review on master by Csaba Henk (csaba@redhat.com)
Comment 13 Worker Ant 2017-01-04 02:10:25 EST
REVIEW: http://review.gluster.org/16313 (fuse: clean up mount flag processing) posted (#6) for review on master by Csaba Henk (csaba@redhat.com)
Comment 14 Worker Ant 2017-01-18 02:20:03 EST
COMMIT: http://review.gluster.org/15766 committed in master by Raghavendra G (rgowdapp@redhat.com) 
------
commit 90cb8c49787d41a46e5b86d73bdc515f54aff4c0
Author: Csaba Henk <csaba@redhat.com>
Date:   Wed Nov 2 07:22:39 2016 +0100

    fuse: limit fusermount fallback to EPERM cases
    
    There are two mount mechanims for fuse:
    1) Call mount(2) syscall directly -- implemented by fuse_mount_sys
    2) Call out to fusermount(1) helper utilty to do the mount --
       implemented by fuse_mount_fusermount
       [Note: both libfuse and glusterfs ships a variant of this helper
       utility; named, respectively, fusermount and fusermount-glusterfs.
       The two has diverged, and are not compatible at the moment.]
    
    The intended use of 1) is privileged mounting, ie. when root
    is invoking the glusterfs client. (It cannot work for non-privileged
    users as the kernel enforces privilege for mount(2), more precisely,
    caller context needs CAP_SYS_ADMIN, see capabilities(7).)
    
    The intended use of 2) is unprivileged mountig, ie. when
    the glusterfs client is invoked by an unprivileged user.
    The helper utility is a setuid binary, so it can perform
    mount(2) on behalf of the user.
    
    The main mount routine, gf_fuse_mount, calls fuse_mount_sys first,
    and if that fails, tries also with fuse_mount_fusermount. This
    is what we call "fusermount fallback". However, in the light of
    the above remarks about intended use, this logic should apply if
    the fuse_mount_fusermount fails because of a privilege shortage,
    ie. with error "Operation not permitted" (errno EPERM).
    
    So far the fallback was unconditional (masking bugs of
    fuser_mount_sys, as it happens in referred BUG). Now we
    add the "errno == EPERM" condition.
    
    BUG: 1297182
    Change-Id: Ia89d975d1e27fcfa5ab2036ba546aa8fa0d2d1b0
    Signed-off-by: Csaba Henk <csaba@redhat.com>
    Reviewed-on: http://review.gluster.org/15766
    Smoke: Gluster Build System <jenkins@build.gluster.org>
    NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org>
    CentOS-regression: Gluster Build System <jenkins@build.gluster.org>
Comment 15 Shyamsundar 2017-03-06 12:20:01 EST
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.10.0, please open a new bug report.

glusterfs-3.10.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] http://lists.gluster.org/pipermail/gluster-users/2017-February/030119.html
[2] https://www.gluster.org/pipermail/gluster-users/
Comment 16 Worker Ant 2017-04-27 13:38:51 EDT
COMMIT: https://review.gluster.org/16313 committed in master by Kaleb KEITHLEY (kkeithle@redhat.com) 
------
commit e624e7fe38a784363c57108c73487d83a7bda562
Author: Csaba Henk <csaba@redhat.com>
Date:   Tue Jan 3 15:26:30 2017 +0100

    fuse: clean up mount flag processing
    
    In general, when one invokes a mount helper program -- basically
    anything that mounts something based on its command line, so thinking of
    mount(8), mount.<fs-type> or fusermount, but also of FUSE servers in
    general, including glusterfs -- the command line arguments that are to
    affect mount(2) are mapped to a bitmask called the mount flags, which is
    passed to mount(2), so that the kernel can interpret the flag bits and
    adjusts properties of the mount accordingly.
    
    There is a traditional syntax for this mechanism as implemented in
    mount(8): one passes "-ocomma,separated,mount,options" and the
    individual option name strings are mapped to flag bits in mount(8).
    
    FUSE further explores this idea and typically the FUSE server command
    lines allow further option names to be used in the "-ooption,name,list"
    which are then separated from the kernel sanctioned option names (to
    which we'll refer as "system mount options") and are passed to a
    platform specific lower level fuse mount helper interface.
    
    The separation of system mount option names and FUSE specific option
    names is also platform specific, so the general mount interface
    function, which in case of glusterfs is gf_fuse_mount(), should abstract
    this away.
    
    Therefore we change the signature of this function from
    
            int gf_fuse_mount (const char *mountpoint, char *fsname,
                               unsigned long mountflags, char *mnt_param,
                               pid_t *mtab_pid, int status_fd);
    
    to
    
            int gf_fuse_mount (const char *mountpoint, char *fsname,
                               char *mnt_param, pid_t *mtab_pid,
                               int status_fd);
    
    and deal with flag extraction in platform specific mount code. Note that
    the sole purpose of the mountflags argument was to indicate read-only
    mounting. The other system mount option names were expected to reside in
    the comma-separated mnt_param string, but they were not properly
    processed (see the referred BUG). With the new gf_fuse_mount signature
    read-only mounting is to be indicated as a "ro" component in mnt_param.
    
    - For Darwin, which has a dedicated, separate gf_fuse_mount
      implementation, gf_fuse_mount was ignoring mountflags, so only the
      signature had to to be adjusted. However, as bonus, we gain read-only
      support for Darwin, which was missing so far, given that it was
      indicated via the ignored mountflags. Darwin's low level mount helper
      relies on the "ro" component of the option string, which agrees with
      the new calling convention of gf_fuse_mount.
    
    - On Linux, system mount option name handling (apart from the
      distinguished read-only option) used to have the inadvertent side
      effect of adding "nosuid,nodev" as indicated in BUG; since
      Ia89d975d1e27fcfa5ab2036ba546aa8fa0d2d1b0 this side effect is removed,
      but system mount option name handling was left broken (passing system
      mount options other than "ro" fails to mount).
    
    - On other platforms, system mount option name handling is broken
      (expect for the distinguished read-only option).
    
    As of this change, in the general (non-Darwin) implementation of
    gf_fuse_mount we take care of proper separation of system mount names
    and their conversion to mount flags. For Linux, we adopt the conversion
    table from FUSE upstream. For other systems we just provide a best
    effort to support those system mount options which are understood across
    all Unices (nosuid,nodev,noatime,noexec,ro). (This can be improved later
    to provide proper plaform support.)
    
    BUG: 1297182
    Change-Id: I5d10b5df46feba7a02bf5bf1018db69e6b52260a
    Signed-off-by: Csaba Henk <csaba@redhat.com>
    Reviewed-on: https://review.gluster.org/16313
    Smoke: Gluster Build System <jenkins@build.gluster.org>
    NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org>
    CentOS-regression: Gluster Build System <jenkins@build.gluster.org>
    Reviewed-by: Amar Tumballi <amarts@redhat.com>
    Tested-by: Amar Tumballi <amarts@redhat.com>
Comment 17 Shyamsundar 2017-05-30 14:32:08 EDT
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.11.0, please open a new bug report.

glusterfs-3.11.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] http://lists.gluster.org/pipermail/announce/2017-May/000073.html
[2] https://www.gluster.org/pipermail/gluster-users/

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