Created attachment 1122349 [details] sosreport -o ovirt,vdsm While testing oVirt Live patches I've seen errors while creating a local storage domain with SELinux enforcing. Moving SELinux to permissive solved the issue. Attaching sosreport for vdsm and engine.
Can you repeat the failed attempt and share the output of: ausearch -m AVC
Hi Sandro Can you please provide more information for the bug reproduction? When you added the host to the system, SELinux was enforcing? or did you set it to enforce only after?
How reproducible: 100% Steps to reproduce: - Add a host to the system with SELinux enfocing, put it on maintenance mode. - Configure a local storage to that host: - - At the host run: - - - mkdir -p /data/images - - - chown 36:36 /data /data/images - - - chmod 0755 /data /data/images - - Configure the path of the local storage to be "/data/images" - - Press "OK" Actual results: Datacenter fails to initialize. Expected results: Datacenter should be initialized successfully.
Amit, Sandro, we need the AVC report from selinux, see comment 1.
Output of ausearch, after a failed operation: --- time->Mon Feb 15 09:10:25 2016 type=SYSCALL msg=audit(1455520225.877:2526): arch=c000003e syscall=2 success=no exit=-13 a0=7eff940009c8 a1=105002 a2=0 a3=1 items=0 ppid=1 pid=31557 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(1455520225.877:2526): avc: denied { read write } for pid=31557 comm="sanlock" name="ids" dev="dm-0" ino=783401 scontext=system_u:system_r:sanlock_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=file --- Output after a successful operation: --------- time->Mon Feb 15 09:12:54 2016 type=SYSCALL msg=audit(1455520374.244:2584): arch=c000003e syscall=5 success=yes exit=0 a0=c a1=7effa6384ad0 a2=7effa6384ad0 a3=0 items=0 ppid=1 pid=31652 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(1455520374.244:2584): avc: denied { getattr } for pid=31652 comm="sanlock" path="/data/images/74f9a70d-671b-4b4f-8b95-9836ff5deac7/dom_md/ids" dev="dm-0" ino=783403 scontext=system_u:system_r:sanlock_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=file
See also: https://bugzilla.redhat.com/show_bug.cgi?id=1278051 I checked local storage on RHEL 7.2 with SELInux Enforcing and it worked fine.
Seems like the issue still exists in 7.2 updated environment ..
Ok, it means there is not a policy rule allowing sanlock_t to access generic default_t type. We need to find a writeable file type label for sanlock. # chcon -R -t virt_var_lib_t /data/images for testing.
So Miroslav, (In reply to Miroslav Grepl from comment #8) > Ok, it means there is not a policy rule allowing sanlock_t to access generic > default_t type. > > We need to find a writeable file type label for sanlock. > > > # chcon -R -t virt_var_lib_t /data/images > > for testing. This makes the flow to succeed, with SELinux enforcing. Miroslav- does that something to be done on our side or yours? Thanks a lot.
(In reply to Amit Aviram from comment #9) > So Miroslav, (In reply to Miroslav Grepl from comment #8) > > Ok, it means there is not a policy rule allowing sanlock_t to access generic > > default_t type. > > > > We need to find a writeable file type label for sanlock. > > > > > > # chcon -R -t virt_var_lib_t /data/images > > > > for testing. > > This makes the flow to succeed, with SELinux enforcing. > Miroslav- does that something to be done on our side or yours? > > Thanks a lot. Yes, it should a part of a script. mkdir -p /data/images semanage fcontext -a -t virt_var_lib_t "/data/images(/.*)? restorecon -R -v /data/images
*** Bug 1278051 has been marked as a duplicate of this bug. ***
We have found out that all of this SELinux label managing is just unnecessary, as the bug is that we are even trying to use sanlock for locking local storage. patch is posted.
Is this a regression in 4.0, or does it reproduce in 3.6.z too? If so, the patch should be backported.
It does not reproduce in 3.6, the patch which introduced this bug exists only in master. (the exact bug is mentioned in my comment in gerrit)
Local DC initialization succeeds using: vdsm-4.17.999-917.gitc116919.el7.centos.noarch selinux-policy-3.13.1-60.el7.noarch ovirt-engine-4.0.0-0.0.master.20160406161747.gita4ecba2.el7.centos.noarch
oVirt 4.0.0 has been released, closing current release.
(In reply to Amit Aviram from comment #14) > It does not reproduce in 3.6, the patch which introduced this bug exists > only in master. (the exact bug is mentioned in my comment in gerrit) I'm affected by this bug on 3.6.8.1-0.1.el6. Setting SELinux to Permissive solve the issue. I think this bug should be opened.
(In reply to ahauser from comment #17) > (In reply to Amit Aviram from comment #14) > > It does not reproduce in 3.6, the patch which introduced this bug exists > > only in master. (the exact bug is mentioned in my comment in gerrit) > > I'm affected by this bug on 3.6.8.1-0.1.el6. > Setting SELinux to Permissive solve the issue. > > I think this bug should be opened. It's a mute point by now, unfortunately. It's solved in 4.0 and there are no more 3.6.z releases. Updating to any vdsm-14.18.z should solve the issue on your env.