Hide Forgot
Description of problem: Regression: After upgrade from RHEL 5.4 to RHEL 5.5, xendomains cannot auto-start domains. Version-Release number of selected component (if applicable): xen-3.0.3-105.el5 selinux-policy-targeted-2.4.6-279.el5 selinux-policy-2.4.6-279.el5 How reproducible: Don't know. Steps to Reproduce: 1. Upgrade from RHEL 5.4 to RHEL 5.5. Actual results: After reboot of domain0, none of the dom-Us (which previously used to auto-start) start. Expected results: The "xendomains" service should auto-start all xen-domains linked to in /etc/xen/auto/ Additional info: When trying to execute "xendomains status", the following output is seen: ===================================================== [root@xenhost auto]# /etc/init.d/xendomains status Checking for xendomains:Error: Unable to open config file: /etc/xen/auto/domu1 Error: Unable to open config file: /etc/xen/auto/domu2 Error: Unable to open config file: /etc/xen/auto/domu3 Error: Unable to open config file: /etc/xen/auto/domu4 MISS AUTO: [dead] ===================================================== Meanwhile, in /var/log/audit/audit.log: ===================================================== type=AVC msg=audit(1270480944.268:377): avc: denied { read } for pid=15095 comm="xm" name="domu1" dev=dm-0 ino=4275876 scontext=user_u:system_r:xm_t:s0 tcontext=system_u:object_r:virt_etc_rw_t:s0 tclass=lnk_file type=SYSCALL msg=audit(1270480944.268:377): arch=c000003e syscall=4 success=no exit=-13 a0=e1c8990 a1=7fffd13740c0 a2=7fffd13740c0 a3=2b9e66740fa8 items=0 ppid=15094 pid=15095 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=36 comm="xm" exe="/usr/bin/python" subj=user_u:system_r:xm_t:s0 key=(null) type=AVC msg=audit(1270480944.268:378): avc: denied { read } for pid=15095 comm="xm" name="domu1" dev=dm-0 ino=4275876 scontext=user_u:system_r:xm_t:s0 tcontext=system_u:object_r:virt_etc_rw_t:s0 tclass=lnk_file type=SYSCALL msg=audit(1270480944.268:378): arch=c000003e syscall=4 success=no exit=-13 a0=e1c8990 a1=7fffd13740c0 a2=7fffd13740c0 a3=0 items=0 ppid=15094 pid=15095 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=36 comm="xm" exe="/usr/bin/python" subj=user_u:system_r:xm_t:s0 key=(null) type=AVC msg=audit(1270480944.272:379): avc: denied { read } for pid=15095 comm="xm" name="domu1" dev=dm-0 ino=4275876 scontext=user_u:system_r:xm_t:s0 tcontext=system_u:object_r:virt_etc_rw_t:s0 tclass=lnk_file type=SYSCALL msg=audit(1270480944.272:379): arch=c000003e syscall=4 success=no exit=-13 a0=e1c8990 a1=7fffd13740c0 a2=7fffd13740c0 a3=0 items=0 ppid=15094 pid=15095 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=36 comm="xm" exe="/usr/bin/python" subj=user_u:system_r:xm_t:s0 key=(null) type=AVC msg=audit(1270480944.460:380): avc: denied { read } for pid=15118 comm="xm" name="domu2" dev=dm-0 ino=4275903 scontext=user_u:system_r:xm_t:s0 tcontext=system_u:object_r:virt_etc_rw_t:s0 tclass=lnk_file type=SYSCALL msg=audit(1270480944.460:380): arch=c000003e syscall=4 success=no exit=-13 a0=10e5a990 a1=7fff9684df10 a2=7fff9684df10 a3=2b64a04eefa8 items=0 ppid=15117 pid=15118 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=36 comm="xm" exe="/usr/bin/python" subj=user_u:system_r:xm_t:s0 key=(null) type=AVC msg=audit(1270480944.460:381): avc: denied { read } for pid=15118 comm="xm" name="domu2" dev=dm-0 ino=4275903 scontext=user_u:system_r:xm_t:s0 tcontext=system_u:object_r:virt_etc_rw_t:s0 tclass=lnk_file type=SYSCALL msg=audit(1270480944.460:381): arch=c000003e syscall=4 success=no exit=-13 a0=10e5a990 a1=7fff9684df10 a2=7fff9684df10 a3=0 items=0 ppid=15117 pid=15118 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=36 comm="xm" exe="/usr/bin/python" subj=user_u:system_r:xm_t:s0 key=(null) type=AVC msg=audit(1270480944.460:382): avc: denied { read } for pid=15118 comm="xm" name="domu2" dev=dm-0 ino=4275903 scontext=user_u:system_r:xm_t:s0 tcontext=system_u:object_r:virt_etc_rw_t:s0 tclass=lnk_file type=SYSCALL msg=audit(1270480944.460:382): arch=c000003e syscall=4 success=no exit=-13 a0=10e5a990 a1=7fff9684df10 a2=7fff9684df10 a3=0 items=0 ppid=15117 pid=15118 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=36 comm="xm" exe="/usr/bin/python" subj=user_u:system_r:xm_t:s0 key=(null) type=AVC msg=audit(1270480944.660:383): avc: denied { read } for pid=15141 comm="xm" name="domu3" dev=dm-0 ino=4275842 scontext=user_u:system_r:xm_t:s0 tcontext=system_u:object_r:virt_etc_rw_t:s0 tclass=lnk_file type=SYSCALL msg=audit(1270480944.660:383): arch=c000003e syscall=4 success=no exit=-13 a0=15a28990 a1=7fff5b1c4cc0 a2=7fff5b1c4cc0 a3=2aded90fdfa8 items=0 ppid=15140 pid=15141 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=36 comm="xm" exe="/usr/bin/python" subj=user_u:system_r:xm_t:s0 key=(null) type=AVC msg=audit(1270480944.660:384): avc: denied { read } for pid=15141 comm="xm" name="domu3" dev=dm-0 ino=4275842 scontext=user_u:system_r:xm_t:s0 tcontext=system_u:object_r:virt_etc_rw_t:s0 tclass=lnk_file type=SYSCALL msg=audit(1270480944.660:384): arch=c000003e syscall=4 success=no exit=-13 a0=15a28990 a1=7fff5b1c4cc0 a2=7fff5b1c4cc0 a3=0 items=0 ppid=15140 pid=15141 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=36 comm="xm" exe="/usr/bin/python" subj=user_u:system_r:xm_t:s0 key=(null) type=AVC msg=audit(1270480944.660:385): avc: denied { read } for pid=15141 comm="xm" name="domu3" dev=dm-0 ino=4275842 scontext=user_u:system_r:xm_t:s0 tcontext=system_u:object_r:virt_etc_rw_t:s0 tclass=lnk_file type=SYSCALL msg=audit(1270480944.660:385): arch=c000003e syscall=4 success=no exit=-13 a0=15a28990 a1=7fff5b1c4cc0 a2=7fff5b1c4cc0 a3=0 items=0 ppid=15140 pid=15141 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=36 comm="xm" exe="/usr/bin/python" subj=user_u:system_r:xm_t:s0 key=(null) type=AVC msg=audit(1270480944.864:386): avc: denied { read } for pid=15164 comm="xm" name="domu4" dev=dm-0 ino=4275846 scontext=user_u:system_r:xm_t:s0 tcontext=system_u:object_r:virt_etc_rw_t:s0 tclass=lnk_file type=SYSCALL msg=audit(1270480944.864:386): arch=c000003e syscall=4 success=no exit=-13 a0=3936990 a1=7fff044e48f0 a2=7fff044e48f0 a3=2b1faab06fa8 items=0 ppid=15163 pid=15164 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=36 comm="xm" exe="/usr/bin/python" subj=user_u:system_r:xm_t:s0 key=(null) type=AVC msg=audit(1270480944.864:387): avc: denied { read } for pid=15164 comm="xm" name="domu4" dev=dm-0 ino=4275846 scontext=user_u:system_r:xm_t:s0 tcontext=system_u:object_r:virt_etc_rw_t:s0 tclass=lnk_file type=SYSCALL msg=audit(1270480944.864:387): arch=c000003e syscall=4 success=no exit=-13 a0=3936990 a1=7fff044e48f0 a2=7fff044e48f0 a3=0 items=0 ppid=15163 pid=15164 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=36 comm="xm" exe="/usr/bin/python" subj=user_u:system_r:xm_t:s0 key=(null) type=AVC msg=audit(1270480944.864:388): avc: denied { read } for pid=15164 comm="xm" name="domu4" dev=dm-0 ino=4275846 scontext=user_u:system_r:xm_t:s0 tcontext=system_u:object_r:virt_etc_rw_t:s0 tclass=lnk_file type=SYSCALL msg=audit(1270480944.864:388): arch=c000003e syscall=4 success=no exit=-13 a0=3936990 a1=7fff044e48f0 a2=7fff044e48f0 a3=0 items=0 ppid=15163 pid=15164 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=36 comm="xm" exe="/usr/bin/python" subj=user_u:system_r:xm_t:s0 key=(null) =====================================================
"restorecon -R -v /etc/xen" doesn't seem to help, by the way.
More by-the-ways: [root@xenhost ~]# ls -laZ /etc/xen drwx------ root root system_u:object_r:virt_etc_t:s0 . drwxr-xr-x root root system_u:object_r:etc_t:s0 .. drwxr-xr-x root root system_u:object_r:virt_etc_rw_t:s0 auto -rw------- root root system_u:object_r:virt_etc_t:s0 domu1 -rwxr-xr-x root root system_u:object_r:bin_t:s0 qemu-ifup drwxr-xr-x root root system_u:object_r:bin_t:s0 scripts -rw------- root root system_u:object_r:virt_etc_t:s0 domu2 -rw------- root root system_u:object_r:virt_etc_t:s0 domu3 -rw------- root root system_u:object_r:virt_etc_t:s0 domu4 -rw-r--r-- root root system_u:object_r:virt_etc_t:s0 xend-config.sxp -rw-r--r-- root root system_u:object_r:virt_etc_t:s0 xend-pci-permissive.sxp -rw-r--r-- root root system_u:object_r:virt_etc_t:s0 xend-pci-quirks.sxp -rw-r--r-- root root system_u:object_r:virt_etc_t:s0 xmexample1 -rw-r--r-- root root system_u:object_r:virt_etc_t:s0 xmexample2 -rw-r--r-- root root system_u:object_r:virt_etc_t:s0 xmexample.hvm -rw-r--r-- root root system_u:object_r:virt_etc_t:s0 xmexample.vti [root@xenhost ~]# ls -laZ /etc/xen/auto/ drwxr-xr-x root root system_u:object_r:virt_etc_rw_t:s0 . drwx------ root root system_u:object_r:virt_etc_t:s0 .. lrwxrwxrwx root root system_u:object_r:virt_etc_rw_t:s0 domu1 -> ../domu1 lrwxrwxrwx root root system_u:object_r:virt_etc_rw_t:s0 domu2 -> ../domu2 lrwxrwxrwx root root system_u:object_r:virt_etc_rw_t:s0 domu3 -> ../domu3 lrwxrwxrwx root root system_u:object_r:virt_etc_rw_t:s0 domu4 -> ../domu4
Final "by-the-way": [root@xenhost ~]# ls -laZ /usr/sbin/xm -rwxr-xr-x root root system_u:object_r:xm_exec_t:s0 /usr/sbin/xm
Miroslav, Add manage_lnk_files_pattern($1, virt_etc_rw_t, virt_etc_rw_t) to virt_manage_config
Troels, You can add this policy for now by executing # grep xm_t /var/log/audit/audit.log | audit2allow -M myxen # semodule -i myxen.pp
Daniel: Thanks, that made the problem go away.
When will this be fixed the regular way with an update of selinux-policy?
It will definitely be fixed in RHEL5.6. And I will be putting out previews when Miroslav has prepared a fix. If RHEL5.5 is has a zstream, you can request the fix there. Although I forget whether it has one.
*** Bug 592947 has been marked as a duplicate of this bug. ***
*** Bug 599540 has been marked as a duplicate of this bug. ***
Preview of selinux-policy-2.4.6-280.el5.noarch, which contains the fix, is available on http://people.redhat.com/dwalsh/SELinux/RHEL5/noarch
*** Bug 611908 has been marked as a duplicate of this bug. ***
Fixed in selinux-policy-2.4.6-281.el5.noarch.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: After upgrading to Red Hat Enterprise Linux 5.5, the Xen hypervisor was unable to auto-start domains linked to in the /etc/xen/auto/ directory. This was caused by the default Red Hat Enterprise Linux 5.5 SELinux policy preventing the xm daemon from reading the symlinks in the /etc/xen/auto directory, with the result that the xm daemon could not start the virtual guests. These updated selinux-policy packages contain an updated SELinux policy that allows the xm daemon to correctly read the symbolic links in /etc/xen/auto. The xm service is now able to auto-start virtual guests upon system startup.
QA verified this bug on RHEL5.5 with the following package: xen-3.0.3-115.el5 selinux-policy-strict-2.4.6-282.el5 selinux-policy-targeted-2.4.6-282.el5 selinux-policy-devel-2.4.6-282.el5 selinux-policy-minimum-2.4.6-282.el5 selinux-policy-mls-2.4.6-282.el5 selinux-policy-2.4.6-282.el5 With the patch, domains could be created automatically after host rebooting. Without the patch, domains couldn't be created. And there are errors logged in /var/log/audit/audit.log. So change this bug to VERIFIED.
I don't have Xen virtualization any longer. But before we (recently) switched to KVM, the problem seemed to have gone away, probably due to Xen-relatede package updates. I think this bug can be closed.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -After upgrading to Red Hat Enterprise Linux 5.5, the Xen hypervisor was unable to auto-start domains linked to in the /etc/xen/auto/ directory. This was caused by the default Red Hat Enterprise Linux 5.5 SELinux policy preventing the xm daemon from reading the symlinks in the /etc/xen/auto directory, with the result that the xm daemon could not start the virtual guests. These updated selinux-policy packages contain an updated SELinux policy that allows the xm daemon to correctly read the symbolic links in /etc/xen/auto. The xm service is now able to auto-start virtual guests upon system startup.+After upgrading to Red Hat Enterprise Linux 5.5, the Xen hypervisor was unable to auto-start domains linked to in the /etc/xen/auto/ directory. This was caused by the default Red Hat Enterprise Linux 5.5 SELinux policy preventing the xm daemon from reading symbolic links in the /etc/xen/auto/ directory, with the result that the xm daemon could not start virtual guests. These updated selinux-policy packages contain an updated SELinux policy that allows the xm daemon to correctly read the symbolic links in /etc/xen/auto/. The xm service is now able to auto-start virtual guests upon system startup.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0026.html