Description of problem: While installing the ISO on VM from RHEVM, we see some permission denied errors. Running sealert on audit log shows selinux preventing access to the file on the storage. Selinux is set to permissive mode on RHS cluster and set to enforcing mode on the hypervisor which is a RHEL 6.3 machine. Version-Release number of selected component (if applicable): RHEL 6.3 on hypervisor RHS2.0 on glusterfs servers with glusterfs-3.3.0rhsvirt1-2.el6_2.x86_64 rhevm-webadmin-portal-3.1.0-15.el6ev.noarch How reproducible: Consistently Steps to Reproduce: 1. Install ISO on VM from RHEVM 2. 3. Actual results: Installing from ISO on VM fails. Expected results: Should set the right selinux context and succeed. Additional info: Setting selinux to permissive mode on hypervisor fixes the issue. sealert output: SELinux is preventing /usr/sbin/sanlock from search access on the directory /. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that sanlock should be allowed search access on the directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep sanlock /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp -------------------------------------------------------------------------------- SELinux is preventing /usr/sbin/sanlock from getattr access on the file /rhev/data-center/mnt/rhs-gp-srv11.lab.eng.blr.redhat.com:_distribute-replicate-2x2/62bebb34-33c1-4329-9b69-e88dda3dc482/dom_md/ids. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that sanlock should be allowed getattr access on the ids file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep sanlock /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp
Please state which version of selinux policy you are using as well as sanlock RPM. Regardless, it's not a REHVM backend bug.
# rpm -qa | grep sanlock sanlock-2.3-3.el6_3.x86_64 sanlock-lib-2.3-3.el6_3.x86_64 sanlock-python-2.3-3.el6_3.x86_64 # rpm -qa | grep selinux libselinux-2.0.94-5.3.el6.x86_64 libselinux-utils-2.0.94-5.3.el6.x86_64 selinux-policy-3.7.19-155.el6_3.noarch selinux-policy-targeted-3.7.19-155.el6_3.noarch libselinux-python-2.0.94-5.3.el6.x86_64
If you cut off the alert message we do not see the AVC's and can not diagnose the problem. Please attach the avc messages.
type=AVC msg=audit(1350303946.329:19488): avc: denied { search } for pid=3147 comm="sanlock" name="mnt" dev=sda3 ino=22544387 scontext=system_u:system_r:sanlock_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=dir type=AVC msg=audit(1350303946.329:19488): avc: denied { search } for pid=3147 comm="sanlock" name="/" dev=fuse ino=1 scontext=system_u:system_r:sanlock_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fusefs_t:s0 tclass=dir type=AVC msg=audit(1350303946.329:19488): avc: denied { read write } for pid=3147 comm="sanlock" name="leases" dev=fuse ino=10431266204161846275 scontext=system_u:system_r:sanlock_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fusefs_t:s0 tclass=file type=AVC msg=audit(1350303946.329:19488): avc: denied { open } for pid=3147 comm="sanlock" name="leases" dev=fuse ino=10431266204161846275 scontext=system_u:system_r:sanlock_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fusefs_t:s0 tclass=file type=SYSCALL msg=audit(1350303946.329:19488): arch=c000003e syscall=2 success=yes exit=10 a0=7f3490020578 a1=105002 a2=0 a3=0 items=0 ppid=1 pid=3147 auid=4294967295 uid=179 gid=179 euid=179 suid=179 fsuid=179 egid=179 sgid=179 fsgid=179 tty=(none) ses=4294967295 comm="sanlock" exe="/usr/sbin/sanlock" subj=system_u:system_r:sanlock_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1350303946.331:19489): avc: denied { getattr } for pid=3147 comm="sanlock" path="/rhev/data-center/mnt/rhs-client36.lab.eng.blr.redhat.com:_dist-replica/7746e77b-7475-4fb8-ab7f-fd85773c5762/dom_md/leases" dev=fuse ino=10431266204161846275 scontext=system_u:system_r:sanlock_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fusefs_t:s0 tclass=file type=SYSCALL msg=audit(1350303946.331:19489): arch=c000003e syscall=5 success=yes exit=0 a0=a a1=7f34a0900590 a2=7f34a0900590 a3=0 items=0 ppid=1 pid=3147 auid=4294967295 uid=179 gid=179 euid=179 suid=179 fsuid=179 egid=179 sgid=179 fsgid=179 tty=(none) ses=4294967295 comm="sanlock" exe="/usr/sbin/sanlock" subj=system_u:system_r:sanlock_t:s0-s0:c0.c1023 key=(null)
You seem to have a file system mounted at /mnt without labels "file_t". Have you tried to turn on sanlock_use_fusefs boolean? setsebool -P sanlock_use_fusefs 1 I know this boolean is in selinux-policy-3.7.19-171.el6 for RHEL6.4 Currently available on http://people.redhat.com/dwalsh/SELinux/RHEL6/noarch/
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. http://rhn.redhat.com/errata/RHBA-2013-0314.html