Bug 820843

+++ This bug was initially created as a clone of Bug #811672 +++

Description of problem:

Mountbroker is a service provided by glusterd that can be used to request certain (pre-configured) glusterfs mounts and unmount them.

Mountbroker mounts succeed, but the unmount part fails with EACCES on RHEL-6.2 -- it seems to be caused by RHEL-specific security settings. Invoking umount(8) from shell (with same arguments as passed by glusterd) we succeed.

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


How reproducible:

Deterministically.

Steps to Reproduce:

1. Set up mountbroker as described in RHS User Guide 9.2.5.2. (you may omit the creation of geogroup and the corresponding "option geo-replication-log-group geogroup" volume option)

2. mount the volume (here I use "slavevol", as in above doc) through mountbroker with following command:

# gluster system:: mount geoaccount user-map-root=geoaccount xlator-option=\*-dht.assert-no-child-down=true volfile-server=localhost volfile-id=slavevol client-pid=-1

This will give you back a path of the form /var/mountbroker-root/mb_hive/<mount id>

3. take down the above mount through mountbroker with following command:

# gluster system:: umount /var/mountbroker-root/mb_hive/<mount id>
  
Actual results:

We get back the message "umount failed" and the above command exits with 1.

Expected results:

We don't get any output and the above command exits with 0.

Additional info:

Stracing glusterd with following command:

# strace -s500 -f -eumount -p `cat /var/run/glusterd.pid`

displays

... umount("/var/mountbroker-root/mb_hive/mntTOKUsE", 0) = -1 EACCES (Permission denied)

--- Additional comment from csaba on 2012-04-11 12:59:48 EDT ---

For your ease, the RHS url:

http://docs.redhat.com/docs/en-US/Red_Hat_Storage/2/html/User_Guide/ch09s02s05s02.html

--- Additional comment from jdarcy on 2012-04-11 13:07:42 EDT ---

Anything in the audit log?

--- Additional comment from enakai on 2012-05-09 05:07:31 EDT ---

I suspect this is caused by SELinux. Here's the audit log.

-----
May  9 09:01:30 rhs20b2-02 kernel: type=1400 audit(1336554090.683:5): avc:  denied  { read } for  pid=2130 comm="umount" name="mnt48dS2M" dev=vda2 ino=29940 scontext=unconfined_u:system_r:mount_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=lnk_file
-----

And because of this, geo-replication with an unprivileged user, such as below, fails.

# gluster vol geo-replication vol01 geoaccount@rhs20b2-02::vol01_slave


A workaround is to "setenforce 0", but the final resolution should be an appropriate context labeling....