Description of problem: VM is not lanuched when using libvirt since selinux prevents libvirtd to connect to /var/run/sanlock/sanlock.sock, See the AVC: type=AVC msg=audit(1410296138.576:290): avc: denied { connectto } for pid=6707 comm="libvirtd" path="/var/run/sanlock/sanlock.sock" scontext=system_u:system_r:svirt_t:s0:c190,c297 tcontext=system_u:system_r:sanlock_t:s0-s0:c0.c1023 tclass=unix_stream_socket ls -Z /var/run/sanlock/sanlock.sock srw-rw----. sanlock sanlock system_u:object_r:sanlock_var_run_t:s0 /var/run/sanlock/sanlock.sock Version-Release number of selected component (if applicable): selinux-policy-3.7.19-254 libvirt-0.10.2-29.el6_5.12.x86_64 How reproducible: Always Steps to Reproduce: 1. Start a VM managed by libvirt Actual results: Acces denied Expected results: Access allowed Additional info:
Did you enable the virt_use_sanlock boolean ?
(In reply to Milos Malik from comment #2) > Did you enable the virt_use_sanlock boolean ? Hm I did not, It helps, but something should turn it on, in RHEVM environment. I am moving to vdsm then. I guess vdsm should turn the seboolean virt_use_sanlock to on. vdsm-4.16.3-2.el6.x86_64
Actually all of the seboleans from vdsm/tool/seboolsetup.py are off: "virt_use_fusefs", "virt_use_nfs", "virt_use_samba", "virt_use_sanlock", "sanlock_use_fusefs", "sanlock_use_nfs", "sanlock_use_samba",
#============= svirt_t ============== #!!!! This avc can be allowed using the boolean 'virt_use_sanlock' allow svirt_t sanlock_t:unix_stream_socket connectto;
These selinux booleans are already configured by VDSM. However, the selinux configuration is run only after vdsm is installed or before it was removed. For example, quoting vdsm.spec: %post %{_bindir}/vdsm-tool configure --module sanlock --force >/dev/null %{_bindir}/vdsm-tool sebool-config || : # set the vdsm "secret" password for libvirt %{_bindir}/vdsm-tool set-saslpasswd
(In reply to Francesco Romani from comment #6) > These selinux booleans are already configured by VDSM. > > However, the selinux configuration is run only after vdsm is installed or > before it was removed. For example, quoting vdsm.spec: > > %post > %{_bindir}/vdsm-tool configure --module sanlock --force >/dev/null > %{_bindir}/vdsm-tool sebool-config || : > # set the vdsm "secret" password for libvirt > %{_bindir}/vdsm-tool set-saslpasswd and my observation is that they are not set when vdsm is installed on RHEL6 hosts that's why I created a bug.
can you run manually "vdsm-tool sebool-config" and tell if it creates the missing policies? mooli, can you reproduce it and check if we call the sebool-config as we used to during the rpm installation or we added some kind of regression in that area?
*** Bug 1142739 has been marked as a duplicate of this bug. ***
(In reply to Yaniv Bronhaim from comment #8) > can you run manually "vdsm-tool sebool-config" and tell if it creates the > missing policies? # vdsm-tool sebool-config Traceback (most recent call last): File "/usr/bin/vdsm-tool", line 209, in main return tool_command[cmd]["command"](*args) File "/usr/lib64/python2.6/site-packages/vdsm/tool/seboolsetup.py", line 66, in sebool_config setup_booleans(True) File "/usr/lib64/python2.6/site-packages/vdsm/tool/seboolsetup.py", line 53, in setup_booleans sebool_obj.finish() File "/usr/lib64/python2.6/site-packages/seobject.py", line 320, in finish self.commit() File "/usr/lib64/python2.6/site-packages/seobject.py", line 309, in commit semanage_set_reload(self.sh, self.load) AttributeError: booleanRecords instance has no attribute 'load'
Looks like the bug is in your policycoreutils-python package. can you check what version do you use (run "rpm -q policycoreutils-python") in my rhel 6.5 setup I use policycoreutils-python-2.0.83-19.39.el6.x86_64 which works fine
(In reply to Yaniv Bronhaim from comment #12) > Looks like the bug is in your policycoreutils-python package. can you check > what version do you use (run "rpm -q policycoreutils-python") > > in my rhel 6.5 setup I use policycoreutils-python-2.0.83-19.39.el6.x86_64 > which works fine policycoreutils-python-2.0.83-19.47.el6.x86_64
I tested on policycoreutils-python-2.0.83-19.39.el6.x86_64 and everything seems fine. I could not locate policycoreutils-python-2.0.83-19.47 on brew/on the internet. What repo is it coming from("yum list policycoreutils-python")? are there steps to reproduce this on a fresh host? I would very much like access to that machine. Please ping me (mtayer) on #vdsm PS the code of seobject.py that I get looks very different from that throwing the exception above (semanage_set_reload is a function defined in semanage.py and not seobject.py) this looks strange to me for a different release(39 vs 47) only? but I'm not sure what to make of it. I will try to catch the packager also.
Tested on the rhel 6.6 machine where this occurred. AFAIU, as yaniv suggested, there is a problem with policycoreutils-python. The following succeeds with: policycoreutils-python-2.2.5-4.fc20.x86_64 (fe20 current) and policycoreutils-python-2.0.83-19.39.el6.x86_64 (el6.4 current). But fails with: policycoreutils-python-2.0.83-19.47.el6.x86_64(el6.6 current?) $ python ... >>> import seobject >>> seobject.booleanRecords().modify('virt_use_samba','on') Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib64/python2.6/site-packages/seobject.py", line 2102, in modify self.commit() File "/usr/lib64/python2.6/site-packages/seobject.py", line 309, in commit semanage_set_reload(self.sh, self.load) AttributeError: booleanRecords instance has no attribute 'load'
Created attachment 943008 [details] policycoreutils seobject.patch Could you try to apply the following patch. Basically we implemented a new optioni in RHEL6.6 which causes now this issue.
It should work with https://brewweb.devel.redhat.com/buildinfo?buildID=369418 policycoreutils builds without a new option.
Marian I've do not access to the machine. can you please try to downgrade to policycoreutils-2.0.83-19.43.el6 If not ping me and we can apply the one line patch to the machine.
# rpm -qa | grep policycore policycoreutils-2.0.83-19.43.el6.x86_64 policycoreutils-python-2.0.83-19.43.el6.x86_64 # vdsm-tool sebool-config Traceback (most recent call last): File "/usr/bin/vdsm-tool", line 209, in main return tool_command[cmd]["command"](*args) File "/usr/lib64/python2.6/site-packages/vdsm/tool/seboolsetup.py", line 66, in sebool_config setup_booleans(True) File "/usr/lib64/python2.6/site-packages/vdsm/tool/seboolsetup.py", line 53, in setup_booleans sebool_obj.finish() File "/usr/lib64/python2.6/site-packages/seobject.py", line 320, in finish self.commit() File "/usr/lib64/python2.6/site-packages/seobject.py", line 309, in commit semanage_set_reload(self.sh, self.load) AttributeError: booleanRecords instance has no attribute 'load' But applying the one liner helps and it seems to work as expected.
do we want to add a specific dependency on a new selinux package?
If case the bugfix in policycoreutils-python will reach 6.6 GA, won't the erroneous minor releases be untagged? (the bug effect everyone and not just us.) Dan?
Aside from handling the dependency issue, I think error handling needs improvement. We ignore it so we won't fail due to disabled selinux. In cases where the failure is from a different unknown reason, we get a broken installation - as seen here and ovirt-host-deploy succeeds. (though we do get log error.) Patch suggested.
(In reply to Mooli Tayer from comment #22) > If case the bugfix in policycoreutils-python will reach 6.6 GA, > won't the erroneous minor releases be untagged? > > (the bug effect everyone and not just us.) > > Dan? The fix is expected to be on 0day errata, and reach everybody. HOWEVER, QE are notorious of having partially-updated machines. Adding an explicit requirement in spec is just another way to ensure that you won't need to debug the same bug again. Swallowing only the expected error (in case selinux is disabled) is a good idea.
INO The version bump patch (33771) should make 3.5.0 The swallow errors patch (33737) should probably not.
We require only publically-available packages. At least we try. Sometime, we require an upstream version of (say) libvirt which has not Fedora/el6 build yet. But that's reasonable only for important new features, not to avoid a bug in a dependent package.
(In reply to Dan Kenigsberg from comment #27) > We require only publically-available packages. At least we try. Sometime, we > require an upstream version of (say) libvirt which has not Fedora/el6 build > yet. But that's reasonable only for important new features, not to avoid a > bug in a dependent package. So can we fix that in 3.5.0? Will there be a suitable public package at that time frame?
Hi, Please provide more detailed steps for reproduction of a bug, I'm not quite getting the meaning VM managed by libvirt, please add some WEBUI based steps or command list for for reproduction.
Works for me on these components: libvirt-0.10.2-46.el6_6.2.x86_64 vdsm-4.16.7.4-1.el6ev.x86_64 ovirt-hosted-engine-ha-1.2.4-1.el6ev.noarch ovirt-hosted-engine-setup-1.2.1-3.el6ev.noarch sanlock-2.8-1.el6.x86_64 ovirt-host-deploy-1.3.0-1.el6ev.noarch policycoreutils-python-2.0.83-19.47.el6_6.1.x86_64 rhevm-3.5.0-0.20.el6ev.noarch Here is an example of vdsm-tool configure --force: [root@blue-vdsc ~]# vdsm-tool configure --force Checking configuration status... libvirt is already configured for vdsm Running configure... Reconfiguration of libvirt is done. Done configuring modules to VDSM. You have new mail in /var/spool/mail/root
Works for me: policycoreutils-python-2.0.83-19.47.el6_6.1.x86_64 qemu-kvm-rhev-0.12.1.2-2.448.el6.x86_64 ovirt-hosted-engine-setup-1.2.1-4.el6ev.noarch sanlock-2.8-1.el6.x86_64 ovirt-host-deploy-1.3.0-1.el6ev.noarch ovirt-hosted-engine-ha-1.2.4-1.el6ev.noarch libvirt-0.10.2-46.el6_6.2.x86_64 vdsm-4.16.7.5-1.el6ev.x86_64 rhevm-3.5.0-0.21.el6ev.noarch [root@brown-vdsd ~]# vdsm-tool configure --force Checking configuration status... libvirt is already configured for vdsm Running configure... Reconfiguration of libvirt is done. Done configuring modules to VDSM. You have new mail in /var/spool/mail/root [root@brown-vdsd ~]#
Looks that the requirement is currently wrong. still getting this exception in master and 3.5 branch http://gerrit.ovirt.org/#/c/36148/ should be the right requirement.
(In reply to Yaniv Bronhaim from comment #34) > Looks that the requirement is currently wrong. still getting this exception > in master and 3.5 branch > > http://gerrit.ovirt.org/#/c/36148/ should be the right requirement. how do you get any exception? 6.6 is shipping the right version for a month already
> (In reply to Yaniv Bronhaim from comment #34) > > Looks that the requirement is currently wrong. still getting this exception > > in master and 3.5 branch > > > > http://gerrit.ovirt.org/#/c/36148/ should be the right requirement. > > how do you get any exception? 6.6 is shipping the right version for a month > already (In reply to Michal Skrivanek from comment #35) It is indeed: http://mirror.centos.org/centos-6/6.6/updates/x86_64/Packages/policycoreutils-python-2.0.83-19.47.el6_6.1.x86_64.rpm I've looked in that machine and I believe the rpm repo used is out of date. The version bump patch will fail under such circumstances. Please review.
Works for me: # vdsm-tool configure --force Checking configuration status... libvirt is already configured for vdsm Running configure... Reconfiguration of libvirt is done. Done configuring modules to VDSM. vdsm-4.16.8.1-4.el7ev.x86_64 qemu-kvm-rhev-1.5.3-60.el7_0.11.x86_64 mom-0.4.1-4.el7ev.noarch libvirt-client-1.2.8-10.el7.x86_64 policycoreutils-python-2.2.5-15.el7.x86_64 sanlock-3.2.2-2.el7.x86_64