Bug 1257234 - Unable to mount glusterfs at boot when specifying security context
Unable to mount glusterfs at boot when specifying security context
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: glusterfs (Show other bugs)
x86_64 Linux
unspecified Severity medium
: rc
: ---
Assigned To: Bug Updates Notification Mailing List
Depends On:
  Show dependency treegraph
Reported: 2015-08-26 10:48 EDT by David E. Smith
Modified: 2017-12-06 05:39 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-12-06 05:39:14 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David E. Smith 2015-08-26 10:48:32 EDT
Description of problem:
On a RHEL 6 server, with glusterfs (upstream) 3.5.x, I cannot automatically mount filesystems that specify a SELinux security context.

Version-Release number of selected component (if applicable):
Upstream components:

RHEL 6.7 (current as of this morning)

How reproducible:

Steps to Reproduce:
1. Specify a GlusterFS mount to occur at boot, with a security context in the mount options. Example:

gluster1.myorg.edu:/web-content         /var/www/html           glusterfs       defaults,_netdev,noatime,context=unconfined_u:object_r:httpd_sys_rw_content_t:s0,backupvolfile-server=gluster2.myorg.edu,direct-io-mode=disable 0 0

2. Ensure netfs is running, so that it's supposed to automount at boot time (chkconfig netfs on, or similar).

3. Reboot.

Actual results:
The specified location is NOT mounted.

Expected results:
The specified location should be mounted.

Additional info:
Running an audit log through audit2allow suggests this workaround:
#============= glusterd_t ==============
allow glusterd_t fusefs_t:filesystem relabelfrom;

Alternately, removing the context= section from the mount options allows the file system to mount at boot time (but without the desired security context).

Mounting manually (sudo mount /var/www/html) works. 

My guess is that there's some security context that is applied when a command is run manually, but not as part of the init/boot process, that allows the context option to work.
Comment 2 David E. Smith 2015-08-28 10:23:06 EDT
Relevant snippets from /var/log/glusterfs/mountpoint.log:

[2015-08-26 13:54:17.886182] I [glusterfsd.c:1959:main] 0-/usr/sbin/glusterfs: Started running /usr/sbin/glusterfs version 3.5.5 (/usr/sbin/glusterfs --direct-io-mode=disable --fuse-mountopts=noatime,context="unconfined_u:object_r:httpd_sys_rw_content_t:s0" --volfile-server=gluster2.myorg.edu --volfile-server=gluster1.myorg.edu --volfile-id=/web-content --fuse-mountopts=noatime,context="unconfined_u:object_r:httpd_sys_rw_content_t:s0" /var/www/html)
[2015-08-26 13:54:17.888903] I [mount.c:290:gf_fuse_mount] 0-glusterfs-fuse: direct mount failed (Invalid argument), retry to mount via fusermount
[2015-08-26 13:54:17.893184] E [mount.c:298:gf_fuse_mount] 0-glusterfs-fuse: mount of gluster2.myorg.edu:/web-content to /var/www/html (default_permissions,noatime,context="unconfined_u:object_r:httpd_sys_rw_content_t:s0",allow_other,max_read=131072) failed
[2015-08-26 13:54:17.893526] E [glusterfsd.c:1793:daemonize] 0-daemonize: mount failed

(snip: about 80 lines, including the config graph)

[2015-08-26 13:54:18.235921] I [fuse-bridge.c:4857:fuse_thread_proc] 0-fuse: unmounting /var/www/html
[2015-08-26 13:54:18.247031] W [glusterfsd.c:1095:cleanup_and_exit] (-->/lib64/libc.so.6(clone+0x6d) [0x7f377b9ff9ad] (-->/lib64/libpthread.so.0(+0x7a51) [0x7f377c095a51] (-->/usr/sbin/glusterfs(glusterfs_sigwaiter+0xd5) [0x4053e5]))) 0-: received signum (15), shutting down
[2015-08-26 13:54:18.247053] I [fuse-bridge.c:5514:fini] 0-fuse: Unmounting '/var/www/html'.

And from /var/log/audit/audit.log at the same timestamp, give or take a couple hundred milliseconds:

type=AVC msg=audit(1440597257.790:6): avc:  denied  { relabelfrom } for  pid=1548 comm="fusermount-glus" scontext=system_u:system_r:glusterd_t:s0 tcontext=system_u:object_r:fusefs_t:s0 tclass=filesystem
type=SYSCALL msg=audit(1440597257.790:6): arch=c000003e syscall=165 success=no exit=-13 a0=158d290 a1=158c060 a2=158d2f0 a3=406 items=0 ppid=1545 pid=1548 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="fusermount-glus" exe="/usr/bin/fusermount-glusterfs" subj=system_u:system_r:glusterd_t:s0 key=(null)
Comment 3 David E. Smith 2015-08-28 12:40:11 EDT
Note: I cannot reproduce this on Gluster 3.6 or 3.7, but because of a different problem (see bug 1162910).
Comment 5 Jan Kurik 2017-12-06 05:39:14 EST
Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.

The official life cycle policy can be reviewed here:


This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:


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