Red Hat Bugzilla – Bug 1160343
On a Live migration setup with shared NFS storage, nova instance creation will only work if setenforce 0 is called for selinux
Last modified: 2015-08-24 10:48:24 EDT
Description of problem: ======================= On a system setup for live migration, unless selinux is set to permissive, when a user tries to create a nova instance, the following error will be seen in the nova-compute.log 2014-11-03 16:23:35.963 7273 TRACE nova.compute.manager [instance: b5c3c7fe-4f34-478b-8fff-b7a9f83b061e] File "/usr/lib64/python2.6/site-packages/libvirt.py", line 716, in createWithFlag\ s 2014-11-03 16:23:35.963 7273 TRACE nova.compute.manager [instance: b5c3c7fe-4f34-478b-8fff-b7a9f83b061e] if ret == -1: raise libvirtError ('virDomainCreateWithFlags() failed', dom=self\ ) 2014-11-03 16:23:35.963 7273 TRACE nova.compute.manager [instance: b5c3c7fe-4f34-478b-8fff-b7a9f83b061e] libvirtError: internal error Process exited while reading console log output: 2014-\ 11-03T21:23:35.694400Z qemu-kvm: -chardev file,id=charserial0,path=/openstack/instances/b5c3c7fe-4f34-478b-8fff-b7a9f83b061e/console.log: Could not open '/openstack/instances/b5c3c7fe-4f34\ -478b-8fff-b7a9f83b061e/console.log': Permission denied However, if setenforce 0 is run, the nova instance can be created successfully. Note also that this is seen in the audit log: #============= svirt_t ============== allow svirt_t nova_var_lib_t:file write; So it looks like selinux is preventing libvirt from creating the instance to the nfs mount point. How reproducible ================ Always Steps to Reproduce: ================== 1. Configure a system for live migration 2. create a nova instance * nova boot --flavor 1 --image image-id instance-name Actual results: =============== instance creation fails, and running nova list will show the instance in an ERROR state (see nova-compute.log) Expected results: ================= After instance spawns, it will move into the ACTIVE state
Could you attach raw AVC msg?
Created attachment 958313 [details] audit.log that shows AVC denied Captured the audit.log while setenforce 1 was enabled and live migration was attempted. You will see this in the log: type=AVC msg=audit(1416249751.708:868196): avc: denied { write } for pid=17881 comm="qemu-kvm" name="console.log" dev="0:36" ino=203187846 scontext=system_u:system_r:svirt_tcg_t:s0:c155,c326 tcontext=system_u:object_r:nova_var_lib_t:s0 tclass=file type=SYSCALL msg=audit(1416249751.708:868196): arch=c000003e syscall=2 success=no exit=-13 a0=7f60573150c0 a1=80241 a2=1b6 a3=7fff4dcb8bb0 items=0 ppid=1 pid=17881 auid=4294967295 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107 sgid=107 fsgid=107 tty=(none) ses=4294967295 comm="qemu-kvm" exe="/usr/libexec/qemu-kvm" subj=system_u:system_r:svirt_tcg_t:s0:c155,c326 key=(null)
Given the AVC, this rule seems ok. What do you think Miroslav? allow svirt_t nova_var_lib_t:file write;
Where is "console.log" located?
I am still hitting this issue with the latest RHOS 6.0 Was there additional information needed? I have a setup to provide information if it is needed.
What directory is 'console.log' in? I'm curious what its path is.
Created attachment 981585 [details] Some steps showing how a repro
Testing the above AVC with 0.6.37 and it passes: type=AVC msg=audit(1416249751.708:868196): avc: denied { write } for pid=17881 comm="qemu-kvm" name="console.log" dev="0:36" ino=203187846 scontext=system_u:system_r:svirt_tcg_t:s0:c155,c326 tcontext=system_u:object_r:nova_var_lib_t:s0 tclass=file Was caused by: Unknown - would be allowed by active policy Possible mismatch between this policy and the one under which the audit message was generated. Possible mismatch between current in-memory boolean settings vs. permanent ones.
Moving the bug to verified as I can create instance with selinux turned on. Version ========= [root@lynx13 ~(keystone_admin)]# yum list installed | grep openstack-nova openstack-nova-api.noarch 2014.2.3-25.el7ost @rhelosp-6.0-puddle openstack-nova-cert.noarch 2014.2.3-25.el7ost @rhelosp-6.0-puddle openstack-nova-common.noarch 2014.2.3-25.el7ost @rhelosp-6.0-puddle openstack-nova-conductor.noarch 2014.2.3-25.el7ost @rhelosp-6.0-puddle openstack-nova-console.noarch 2014.2.3-25.el7ost @rhelosp-6.0-puddle openstack-nova-novncproxy.noarch 2014.2.3-25.el7ost @rhelosp-6.0-puddle openstack-nova-scheduler.noarch 2014.2.3-25.el7ost @rhelosp-6.0-puddle Logs ==== [root@lynx13 ~(keystone_admin)]# sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Max kernel policy version: 28 [root@lynx13 ~(keystone_admin)]# [root@lynx13 ~(keystone_admin)]# nova list +--------------------------------------+------------------+--------+------------+-------------+---------------------+ | ID | Name | Status | Task State | Power State | Networks | +--------------------------------------+------------------+--------+------------+-------------+---------------------+ | 19e96e49-0b69-4a5a-b81b-80ec1a42048c | instance_cinder | ACTIVE | - | Running | public=172.24.4.227 | | 7a07c0dc-b98b-4e95-9bc3-dbc8ae4cbade | instance_nfsvol1 | ACTIVE | - | Running | public=172.24.4.235 | +--------------------------------------+------------------+--------+------------+-------------+---------------------+ 299 nova boot --flavor m1.tiny --image cirros --block-device source=volume,id=38617a5c-7298-4f2d-a977-50c29cbedd6e,dest=volume,shutdown=preserve instance_nfsvol1
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. https://rhn.redhat.com/errata/RHBA-2015-1659.html