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.
Oop, bug 1294809 is the one that makes it possible again to mount with "-o noatime" and the like.
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.
REVIEW: http://review.gluster.org/15766 (fuse: limit fusermount fallback to EPERM cases) posted (#1) for review on master by Csaba Henk (csaba)
REVIEW: http://review.gluster.org/15766 (fuse: limit fusermount fallback to EPERM cases) posted (#2) for review on master by Csaba Henk (csaba)
REVIEW: http://review.gluster.org/15766 (fuse: limit fusermount fallback to EPERM cases) posted (#3) for review on master by Csaba Henk (csaba)
REVIEW: http://review.gluster.org/16313 (fuse: clean up mount flag processing) posted (#1) for review on master by Csaba Henk (csaba)
REVIEW: http://review.gluster.org/15766 (fuse: limit fusermount fallback to EPERM cases) posted (#4) for review on master by Csaba Henk (csaba)
REVIEW: http://review.gluster.org/16313 (fuse: clean up mount flag processing) posted (#2) for review on master by Csaba Henk (csaba)
REVIEW: http://review.gluster.org/16313 (fuse: clean up mount flag processing) posted (#3) for review on master by Csaba Henk (csaba)
REVIEW: http://review.gluster.org/15766 (fuse: limit fusermount fallback to EPERM cases) posted (#5) for review on master by Csaba Henk (csaba)
REVIEW: http://review.gluster.org/16313 (fuse: clean up mount flag processing) posted (#4) for review on master by Csaba Henk (csaba)
REVIEW: http://review.gluster.org/16313 (fuse: clean up mount flag processing) posted (#5) for review on master by Csaba Henk (csaba)
REVIEW: http://review.gluster.org/16313 (fuse: clean up mount flag processing) posted (#6) for review on master by Csaba Henk (csaba)
COMMIT: http://review.gluster.org/15766 committed in master by Raghavendra G (rgowdapp) ------ commit 90cb8c49787d41a46e5b86d73bdc515f54aff4c0 Author: Csaba Henk <csaba> 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> Reviewed-on: http://review.gluster.org/15766 Smoke: Gluster Build System <jenkins.org> NetBSD-regression: NetBSD Build System <jenkins.org> CentOS-regression: Gluster Build System <jenkins.org>
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/
COMMIT: https://review.gluster.org/16313 committed in master by Kaleb KEITHLEY (kkeithle) ------ commit e624e7fe38a784363c57108c73487d83a7bda562 Author: Csaba Henk <csaba> 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> Reviewed-on: https://review.gluster.org/16313 Smoke: Gluster Build System <jenkins.org> NetBSD-regression: NetBSD Build System <jenkins.org> CentOS-regression: Gluster Build System <jenkins.org> Reviewed-by: Amar Tumballi <amarts> Tested-by: Amar Tumballi <amarts>
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/