This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 896706 - Openstack-nova-compute is unable to mount image for data injection when selinux is "Enforcing".
Openstack-nova-compute is unable to mount image for data injection when selin...
Status: CLOSED DUPLICATE of bug 896013
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-selinux (Show other bugs)
2.0 (Folsom)
x86_64 Linux
high Severity urgent
: snapshot4
: 2.1
Assigned To: Lon Hohberger
Yaniv Kaul
: Triaged
Depends On: 876452
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-17 14:50 EST by Perry Myers
Modified: 2013-07-03 22:59 EDT (History)
24 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 876452
Environment:
Last Closed: 2013-02-18 15:25:57 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Perry Myers 2013-01-17 14:50:05 EST
+++ This bug was initially created as a clone of Bug #876452 +++

Description of problem:
When a new VM is requested nova-compute fails to mount image for data injection because selinux policy. After changing selinux to "Permissive" nova-compute is able to mount the image and inject data as expected. 

nbd is not available in RHEL so nova tries to use guestfs.


Version-Release number of selected component (if applicable):
Using CERN Scientific Linux 6.3
nova package -> openstack-nova-2012.1.1-15.el6


How reproducible:
Always


Steps to Reproduce:
1. nova boot --image your_image --flavor your_flavor --file filetest=filetest vmtest
2. check openstack-nova-compute logs

  
Actual results:
guestmount fails to mount image.
(openstack-nova-compute logs)

2012-11-13 09:21:20 INFO nova.virt.libvirt.connection [req-467dff33-e22b-4b74-bedf-64aa16d37e4b b7aa0805440f41bfa69b000bb475a0eb 237745f6e81d4a8494eea1b168d73610] [instance: 6c4ca58b-f187-45db-8173-b7559a780512] Injecting metadata into image 95bd46d9-6c53-46b5-b3cf-9622b28f66cd
2012-11-13 09:21:20 INFO nova.virt.libvirt.connection [req-467dff33-e22b-4b74-bedf-64aa16d37e4b b7aa0805440f41bfa69b000bb475a0eb 237745f6e81d4a8494eea1b168d73610] [instance: 6c4ca58b-f187-45db-8173-b7559a780512] Injecting key into image 95bd46d9-6c53-46b5-b3cf-9622b28f66cd
2012-11-13 09:21:20 DEBUG nova.virt.disk.api [req-467dff33-e22b-4b74-bedf-64aa16d37e4b b7aa0805440f41bfa69b000bb475a0eb 237745f6e81d4a8494eea1b168d73610] nbd unavailable: module not loaded from (pid=30649) mount /usr/lib/python2.6/site-packages/nova/virt/disk/api.py:205
2012-11-13 09:21:20 DEBUG nova.utils [req-467dff33-e22b-4b74-bedf-64aa16d37e4b b7aa0805440f41bfa69b000bb475a0eb 237745f6e81d4a8494eea1b168d73610] Running cmd (subprocess): sudo nova-rootwrap guestmount --rw -a /var/lib/nova/instances/instance-00000093/disk -i /tmp/tmpVktmfj from (pid=30649) execute /usr/lib/python2.6/site-packages/nova/utils.py:220
2012-11-13 09:21:21 DEBUG nova.utils [req-467dff33-e22b-4b74-bedf-64aa16d37e4b b7aa0805440f41bfa69b000bb475a0eb 237745f6e81d4a8494eea1b168d73610] Result was 1 from (pid=30649) execute /usr/lib/python2.6/site-packages/nova/utils.py:236
2012-11-13 09:21:21 DEBUG nova.utils [req-467dff33-e22b-4b74-bedf-64aa16d37e4b b7aa0805440f41bfa69b000bb475a0eb 237745f6e81d4a8494eea1b168d73610] Unexpected error while running command.
Command: sudo nova-rootwrap guestmount --rw -a /var/lib/nova/instances/instance-00000093/disk -i /tmp/tmpVktmfj
Exit code: 1
Stdout: ''
Stderr: 'libguestfs: error: guestfs_launch failed, see earlier error messages\n' from (pid=30649) trycmd /usr/lib/python2.6/site-packages/nova/utils.py:278
2012-11-13 09:21:21 DEBUG nova.utils [req-467dff33-e22b-4b74-bedf-64aa16d37e4b b7aa0805440f41bfa69b000bb475a0eb 237745f6e81d4a8494eea1b168d73610] Running cmd (subprocess): sudo nova-rootwrap fusermount -u /tmp/tmpVktmfj from (pid=30649) execute /usr/lib/python2.6/site-packages/nova/utils.py:220
2012-11-13 09:21:21 DEBUG nova.utils [req-467dff33-e22b-4b74-bedf-64aa16d37e4b b7aa0805440f41bfa69b000bb475a0eb 237745f6e81d4a8494eea1b168d73610] Result was 1 from (pid=30649) execute /usr/lib/python2.6/site-packages/nova/utils.py:236
2012-11-13 09:21:21 DEBUG nova.utils [req-467dff33-e22b-4b74-bedf-64aa16d37e4b b7aa0805440f41bfa69b000bb475a0eb 237745f6e81d4a8494eea1b168d73610] Unexpected error while running command.
Command: sudo nova-rootwrap fusermount -u /tmp/tmpVktmfj
Exit code: 1
Stdout: ''
Stderr: '/bin/fusermount: failed to unmount /tmp/tmpVktmfj: Invalid argument\n' from (pid=30649) trycmd /usr/lib/python2.6/site-packages/nova/utils.py:278
2012-11-13 09:21:21 DEBUG nova.virt.disk.api [req-467dff33-e22b-4b74-bedf-64aa16d37e4b b7aa0805440f41bfa69b000bb475a0eb 237745f6e81d4a8494eea1b168d73610] Failed to mount filesystem: Unexpected error while running command.
Command: sudo nova-rootwrap guestmount --rw -a /var/lib/nova/instances/instance-00000093/disk -i /tmp/tmpVktmfj
Exit code: 1
Stdout: ''
Stderr: 'libguestfs: error: guestfs_launch failed, see earlier error messages\n' from (pid=30649) mount /usr/lib/python2.6/site-packages/nova/virt/disk/api.py:205
2012-11-13 09:21:21 WARNING nova.virt.libvirt.connection [req-467dff33-e22b-4b74-bedf-64aa16d37e4b b7aa0805440f41bfa69b000bb475a0eb 237745f6e81d4a8494eea1b168d73610] [instance: 6c4ca58b-f187-45db-8173-b7559a780512] Ignoring error injecting data into image 95bd46d9-6c53-46b5-b3cf-9622b28f66cd (
--
nbd unavailable: module not loaded
--
Failed to mount filesystem: Unexpected error while running command.
Command: sudo nova-rootwrap guestmount --rw -a /var/lib/nova/instances/instance-00000093/disk -i /tmp/tmpVktmfj
Exit code: 1
Stdout: ''
Stderr: 'libguestfs: error: guestfs_launch failed, see earlier error messages\n')


Expected results:
mount image for data injection.


Additional info:

in audit.log:
type=AVC msg=audit(1352816002.979:249317): avc:  denied  { read } for pid=2806 comm="qemu-kvm" name="disk" dev=dm-3 ino=656740 scontext=unconfined_u:system_r:qemu_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:nova_var_lib_t:s0 tclass=file
type=SYSCALL msg=audit(1352816002.979:249317): arch=c000003e syscall=2 success=no exit=-13 a0=7fae966dbc20 a1=800 a2=0 a3=65636e6174736e69 items=0 ppid=2797 pid=2806 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=19511 comm="qemu-kvm" exe="/usr/libexec/qemu-kvm" subj=unconfined_u:system_r:qemu_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1352816002.980:249318): avc:  denied  { getattr } for  pid=2806 comm="qemu-kvm" path="/var/lib/nova/instances/instance-000000a7/disk" dev=dm-3 ino=656740 scontext=unconfined_u:system_r:qemu_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:nova_var_lib_t:s0 tclass=file
type=SYSCALL msg=audit(1352816002.980:249318): arch=c000003e syscall=4 success=no exit=-13 a0=7fae966dbc20 a1=7fffedb37730 a2=7fffedb37730 a3=65636e6174736e69 items=0 ppid=2797 pid=2806 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=19511 comm="qemu-kvm" exe="/usr/libexec/qemu-kvm" subj=unconfined_u:system_r:qemu_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1352816002.980:249319): avc:  denied  { read } for pid=2806 comm="qemu-kvm" name="disk" dev=dm-3 ino=656740 scontext=unconfined_u:system_r:qemu_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:nova_var_lib_t:s0 tclass=file 


# setsebool -P allow_unconfined_qemu_transition 0
libsemanage.dbase_llist_set: record not found in the database (No such file or directory).
libsemanage.dbase_llist_set: could not set record value (No such file or directory).
Could not change boolean allow_unconfined_qemu_transition
Could not change policy booleans 


selinux-policy-targeted-3.7.19-155.el6_3.4

--- Additional comment from Pádraig Brady on 2012-11-14 05:41:49 EST ---

I think this comes under a general theme of allowing services greater access to operations under /var/lib/nova. I.E. 

1. qemu (libguestfs) would like to read images from /var/lib/nova/instances/...

2. The nova_var_lib_t context on /var/lib/nova needs to be configured to allow search access by sshd_t (for the migrate and resize feature)

3. The ssh_home_t context will need to be associated with /var/lib/nova/.ssh
(for the migrate and resize feature)

I would be great if we could at least provide commands to achieve/persist the above 3, so immediate workarounds could be documented.

--- Additional comment from Belmiro Moreira on 2012-11-14 08:20:00 EST ---

Hi Pádraig,

We recently encountered cases 2 and three, which we puppetized away. 

What about changing the %pre install scriptlet of openstack-nova-common to


  if ! getent passwd nova >/dev/null; then
    useradd -u 162 -r -g nova -G nova,nobody -d /var/lib/nova -s /sbin/nologin -c "OpenStack Nova Daemons" nova
    chcon -u system_u -r object_r -t user_home_t /var/lib/nova

    mkdir /var/lib/nova/.ssh
    chmod 700 /var/lib/nova/.ssh
    chcon -u system_u -r object_r -t ssh_home_t /var/lib/nova/.ssh
  fi

--- Additional comment from Pádraig Brady on 2012-11-14 11:19:51 EST ---

Thanks for that Belmiro.

Those SELinux settings are generic and appropriate at the packaging level.
The rest of the config as documented here:
https://fedoraproject.org/wiki/Getting_started_with_OpenStack_EPEL#Migrate_and_Resize
would be site specific and best done outside the package level.

Note I'd probably add that SELinux config to the openstack-nova-compute
subpackage only, as that's the only one that needs the migrate and resize feature,
and use a single mkdir call like:

  # To support migrate and resize, using ssh
  chcon -u system_u -r object_r -t user_home_t /var/lib/nova
  mkdir -p -m 700 --context=system_u:object_r:ssh_home_t:s0 /var/lib/nova/.ssh

BTW, I'm guessing in future this feature will be better integrated in nova upstream, and so may not need to rely on ssh directly in future?

Anyway let's move this bug just back to the specific issue in comment #1

--- Additional comment from Alan Pevec on 2012-11-14 14:05:13 EST ---

chcon-ing is not a proper way to make selinux file context changes, it should be done with semanage fcontext -a ... otherwise next restorecon will revert it.

https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-SELinux_Contexts_Labeling_Files-Persistent_Changes_semanage_fcontext.html

--- Additional comment from Pádraig Brady on 2012-11-21 06:31:58 EST ---

These audit2allow logs from enakai@redhat.com from his compute node are probably related:

#============= qemu_t ==============
#!!!! The source type 'qemu_t' can write to a 'file' of the following types:
# virt_image_type, virt_cache_t, xen_image_t, qemu_var_run_t, anon_inodefs_t, qemu_tmp_t, qemu_image_t, qemu_tmpfs_t, tmpfs_t, nfs_t, usbfs_t, cifs_t, dosfs_t

allow qemu_t nova_var_lib_t:file { read write ioctl open getattr };
allow qemu_t self:capability dac_override;

#============= svirt_t ==============
allow svirt_t self:tun_socket relabelto;
allow svirt_t virtd_t:tun_socket relabelfrom;

--- Additional comment from Nikola Dipanov on 2012-11-27 06:29:44 EST ---

Ataching a policy module that solves the issue on RHEL 6.3 (simmilar to what is described in comment #5 ). All you need to do is:

# checkmodule -m -M nova_qemu_compiled.te -o nova_qemu_compiled.mod
# semodule_package -m nova_qemu_compiled.mod -o nova_qemu_compiled.pp
# semodule -i nova_qemu_compiled.pp

--- Additional comment from Nikola Dipanov on 2012-11-27 06:30:33 EST ---

Created attachment 652638 [details]
policy module that fixes the issue

--- Additional comment from Pádraig Brady on 2012-12-10 08:40:53 EST ---

While the policy in comment #7 may work, probably a more abstract policy is appropriate. I.E. add central policies for /var/lib/nova/instances... to virt_image_t and /var/lib/nova/.ssh to ssh_home_t etc.

Nikola was going to check whether the same issue applied to Fedora,
(while double checking the more abstract settings work),
and then reassign this bug to selinux-policy with details.

A caveat to note is that nova may create directories in certain cases,
especially when dealing with shared storage, so we may need to
look at this upstream too in the ensure_tree() nova call,
which may need to try and `restorecon the_new_tree` to cover these cases.
Comment 1 Miroslav Grepl 2013-01-17 16:01:24 EST
We need to see AVC msgs with

# setenforce 1
# echo "-w /etc/shadow -p w" >> /etc/audit/audit.rules
# service auditd restart
# chcon -R -t virt_image_t /var/lib/nova/instances
# chcon -R -t ssh_home_t /var/lib/nova/.ssh
# setenforce 0

re-test it and

# ausearch -m avc -ts recent
Comment 2 Miroslav Grepl 2013-01-18 03:34:26 EST
This

#============= svirt_t ==============
allow svirt_t self:tun_socket relabelto;
allow svirt_t virtd_t:tun_socket relabelfrom;

seems strange.
Comment 3 Daniel Berrange 2013-01-18 04:22:56 EST
Yep, nothing running under 'svirt_t' should be allowed to relabel, nor should it need to either.
Comment 4 Miroslav Grepl 2013-01-18 04:46:32 EST
Let's wait for AVC msgs.
Comment 5 Nikola Dipanov 2013-01-18 12:40:52 EST
Hi Miroslav, please see below and let me know if smth else is needed.

[root@rhel-test ~(keystone_admin)]$  ausearch -m avc -ts recent
----
time->Fri Jan 18 18:33:22 2013
type=PATH msg=audit(1358530402.404:10585): item=0 name="/var/lib/nova/instances/instance-00000003/disk
" inode=396015 dev=fd:00 mode=0100644 ouid=162 ogid=162 rdev=00:00 obj=unconfined_u:object_r:virt_imag
e_t:s0
type=CWD msg=audit(1358530402.404:10585):  cwd="/"
type=SYSCALL msg=audit(1358530402.404:10585): arch=c000003e syscall=2 success=yes exit=9 a0=7f5a524e2e
00 a1=84002 a2=0 a3=40 items=1 ppid=16679 pid=16688 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sg
id=0 fsgid=0 tty=(none) ses=193 comm="qemu-kvm" exe="/usr/libexec/qemu-kvm" subj=unconfined_u:system_r
:qemu_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1358530402.404:10585): avc:  denied  { dac_override } for  pid=16688 comm="qemu-kvm
" capability=1  scontext=unconfined_u:system_r:qemu_t:s0-s0:c0.c1023 tcontext=unconfined_u:system_r:qe
mu_t:s0-s0:c0.c1023 tclass=capability
----
time->Fri Jan 18 18:33:48 2013
type=PATH msg=audit(1358530428.883:10672): item=0 name="/var/lib/nova/instances/_base/c490d5e02656039b
51f0d56fda0d66d200a83c26" inode=395971 dev=fd:00 mode=0100644 ouid=162 ogid=162 rdev=00:00 obj=unconfi
ned_u:object_r:virt_image_t:s0
type=CWD msg=audit(1358530428.883:10672):  cwd="/"
type=SYSCALL msg=audit(1358530428.883:10672): arch=c000003e syscall=2 success=yes exit=10 a0=7fff35ab1
cc0 a1=800 a2=0 a3=0 items=1 ppid=1 pid=16969 auid=0 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=
107 sgid=107 fsgid=107 tty=(none) ses=193 comm="qemu-system-x86" exe="/usr/libexec/qemu-kvm" subj=unco
nfined_u:system_r:svirt_t:s0:c198,c309 key=(null)
type=AVC msg=audit(1358530428.883:10672): avc:  denied  { open } for  pid=16969 comm="qemu-system-x86"
 name="c490d5e02656039b51f0d56fda0d66d200a83c26" dev=dm-0 ino=395971 scontext=unconfined_u:system_r:sv
irt_t:s0:c198,c309 tcontext=unconfined_u:object_r:virt_image_t:s0 tclass=file
type=AVC msg=audit(1358530428.883:10672): avc:  denied  { read } for  pid=16969 comm="qemu-system-x86"
 name="c490d5e02656039b51f0d56fda0d66d200a83c26" dev=dm-0 ino=395971 scontext=unconfined_u:system_r:sv
irt_t:s0:c198,c309 tcontext=unconfined_u:object_r:virt_image_t:s0 tclass=file
----
time->Fri Jan 18 18:33:48 2013
type=SYSCALL msg=audit(1358530428.883:10673): arch=c000003e syscall=16 success=no exit=-25 a0=a a1=532
6 a2=7fffffff a3=0 items=0 ppid=1 pid=16969 auid=0 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=10
7 sgid=107 fsgid=107 tty=(none) ses=193 comm="qemu-system-x86" exe="/usr/libexec/qemu-kvm" subj=unconf
ined_u:system_r:svirt_t:s0:c198,c309 key=(null)
type=AVC msg=audit(1358530428.883:10673): avc:  denied  { ioctl } for  pid=16969 comm="qemu-system-x86
" path="/var/lib/nova/instances/_base/c490d5e02656039b51f0d56fda0d66d200a83c26" dev=dm-0 ino=395971 sc
ontext=unconfined_u:system_r:svirt_t:s0:c198,c309 tcontext=unconfined_u:object_r:virt_image_t:s0 tclas
s=file
----
time->Fri Jan 18 18:33:48 2013
type=PATH msg=audit(1358530428.883:10674): item=0 name="/var/lib/nova/instances/_base/c490d5e02656039b
51f0d56fda0d66d200a83c26" inode=395971 dev=fd:00 mode=0100644 ouid=162 ogid=162 rdev=00:00 obj=unconfi
ned_u:object_r:virt_image_t:s0
type=CWD msg=audit(1358530428.883:10674):  cwd="/"
type=SYSCALL msg=audit(1358530428.883:10674): arch=c000003e syscall=4 success=yes exit=0 a0=7fff35ab1c
c0 a1=7fff35aafa70 a2=7fff35aafa70 a3=0 items=1 ppid=1 pid=16969 auid=0 uid=107 gid=107 euid=107 suid=
107 fsuid=107 egid=107 sgid=107 fsgid=107 tty=(none) ses=193 comm="qemu-system-x86" exe="/usr/libexec/
qemu-kvm" subj=unconfined_u:system_r:svirt_t:s0:c198,c309 key=(null)
type=AVC msg=audit(1358530428.883:10674): avc:  denied  { getattr } for  pid=16969 comm="qemu-system-x
86" path="/var/lib/nova/instances/_base/c490d5e02656039b51f0d56fda0d66d200a83c26" dev=dm-0 ino=395971 
scontext=unconfined_u:system_r:svirt_t:s0:c198,c309 tcontext=unconfined_u:object_r:virt_image_t:s0 tcl
ass=file
Comment 6 Miroslav Grepl 2013-01-18 13:35:20 EST
Ok, the virt_content_t label will be better

# chcon -R -t virt_content_t /var/lib/nova/instances


Also are images located in /var/lib/nova?


Then "dac_override" is caused by permissions on /var/lib/nova/instances/_base/c490d5e02656039b51f0d56fda0d66d200a83c26

A qemu process does not have permissions (DAC) to access it.
Comment 7 Nikola Dipanov 2013-01-18 14:20:14 EST
Images are in /var/lib/nova/instances (and it's subdirectories, basically every domain (instances) get's it's own subdir).
Comment 8 Miroslav Grepl 2013-01-18 16:05:18 EST
So we have images in subdirs together with random files which are handled to a confined virtual machine.

Did/could you test virt_content_t labeling?
Comment 9 jliberma@redhat.com 2013-01-24 18:12:59 EST
[root@rhos2 nova(keystone_refarch_user)]$ chcon -R -t virt_content_t /var/lib/nova/instances

[root@rhos2 nova(keystone_refarch_user)]$ ls -lZ
drwxr-xr-x. nova nova system_u:object_r:nova_var_lib_t:s0 buckets
drwxr-xr-x. nova nova system_u:object_r:nova_var_lib_t:s0 CA
drwxr-xr-x. nova nova system_u:object_r:nova_var_lib_t:s0 images
drwxr-xr-x. nova nova system_u:object_r:virt_content_t:s0 instances
drwxr-xr-x. nova nova system_u:object_r:nova_var_lib_t:s0 keys
drwxr-xr-x. nova nova system_u:object_r:nova_var_lib_t:s0 networks
drwxr-xr-x. nova nova system_u:object_r:nova_var_lib_t:s0 tmp

[root@rhos2 ~(keystone_refarch_user)]$ nova boot --flavor 2 --key_name rhos2key --image 1610f2af-f927-4f85-b153-1840d7093756 rhel2d

[root@rhos2 ~(keystone_refarch_user)]$ cat /var/log/nova/compute.log 
[snip]
2013-01-24 17:03:18 INFO nova.virt.libvirt.driver [req-773e48cb-07f7-46c8-8339-623767c16ca8 cdddd81ff8b54c72b928c4f7a47cdb94 59a8a05b07224d889e6149d9f826939d] [instance: 74dd6da7-0a99-417a-951e-20e429c5c0fa] Creating image
2013-01-24 17:03:18 INFO nova.virt.libvirt.driver [req-773e48cb-07f7-46c8-8339-623767c16ca8 cdddd81ff8b54c72b928c4f7a47cdb94 59a8a05b07224d889e6149d9f826939d] [instance: 74dd6da7-0a99-417a-951e-20e429c5c0fa] Injecting key into image 1610f2af-f927-4f85-b153-1840d7093756
2013-01-24 17:03:18 WARNING nova.virt.libvirt.driver [req-773e48cb-07f7-46c8-8339-623767c16ca8 cdddd81ff8b54c72b928c4f7a47cdb94 59a8a05b07224d889e6149d9f826939d] [instance: 74dd6da7-0a99-417a-951e-20e429c5c0fa] Ignoring error injecting data into image 1610f2af-f927-4f85-b153-1840d7093756 (
--
nbd unavailable: module not loaded
--
Failed to mount filesystem: Unexpected error while running command.
Command: sudo nova-rootwrap /etc/nova/rootwrap.conf guestmount --rw -a /var/lib/nova/instances/instance-00000010/disk -i /tmp/openstack-disk-mount-tmpIQrHo3
Exit code: 1
Stdout: ''
Stderr: "libguestfs: error: guestfs_launch failed.\nSee http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs\nand/or run 'libguestfs-test-tool'.\n")
Comment 10 Pádraig Brady 2013-01-24 18:35:04 EST
> Failed to mount filesystem: Unexpected error while running command.
> Command: sudo nova-rootwrap /etc/nova/rootwrap.conf guestmount --rw -a /var/lib/nova/instances/instance-00000010/disk -i /tmp/openstack-disk-mount-tmpIQrHo3
> Exit code: 1
> Stderr: "libguestfs: error: guestfs_launch failed

So even though the instance-$id/ directory is created dynamically
it should inherit the context from its parent by default.
So given libguestfs is failing (don't mind the nbd error),
perhaps it does need virt_image_t.

If that doesn't work then I'd run the guestmount command in comment 9 with debugging enabled as per the URL above, which should give better indication as to why it's failing exactly (maybe it's not selinux in this case)
Comment 11 Miroslav Grepl 2013-01-25 04:52:45 EST
Yes, we should have virt_image_t for

drwxr-xr-x. nova nova system_u:object_r:nova_var_lib_t:s0 images
drwxr-xr-x. nova nova system_u:object_r:virt_content_t:s0 instances
Comment 12 Pádraig Brady 2013-01-25 06:14:08 EST
images/ is to support a long since removed local image service in nova.
I'll remove that from nova packaging to avoid confusion.

jliberma and ndipanov have indicated to me that they tried virt_image_t
on /var/lib/nova/instances, but it didn't help.

Re the DAC issue:

$ namei -l /var/lib/nova/instances/instance-00000807/disk
f: /var/lib/nova/instances/instance-00000807/disk
dr-xr-xr-x root root /
drwxr-xr-x root root var
drwxr-xr-x root root lib
drwxr-xr-x nova nova nova
drwxr-xr-x nova nova instances
drwxr-xr-x nova nova instance-00000807
-rw-r--r-- root root disk
Comment 13 Daniel Berrange 2013-01-25 06:22:50 EST
(In reply to comment #10)
> > Failed to mount filesystem: Unexpected error while running command.
> > Command: sudo nova-rootwrap /etc/nova/rootwrap.conf guestmount --rw -a /var/lib/nova/instances/instance-00000010/disk -i /tmp/openstack-disk-mount-tmpIQrHo3
> > Exit code: 1
> > Stderr: "libguestfs: error: guestfs_launch failed
> 
> So even though the instance-$id/ directory is created dynamically
> it should inherit the context from its parent by default.
> So given libguestfs is failing (don't mind the nbd error),
> perhaps it does need virt_image_t.
> 
> If that doesn't work then I'd run the guestmount command in comment 9 with
> debugging enabled as per the URL above, which should give better indication
> as to why it's failing exactly (maybe it's not selinux in this case)

Something is getting mixed up here.  In RHEL-6, libguestfs started QEMU instances are *NOT* confined by sVirt at all. So the AVCs quoted earlier, have nothing todo with this libguestfs failure and thus changing labelling won't affect this.

Only the actual VMs started by libvirt are confined by sVirt & has have relevance for labelling.
Comment 14 Lon Hohberger 2013-02-18 15:05:38 EST
This isn't resolved by the existing openstack-selinux package?

Is this a duplicate of bug 896013 ?
Comment 15 Lon Hohberger 2013-02-18 15:25:57 EST
After rereading the AVCs and talking with Miroslav, I'm pretty sure this is a duplicate.

*** This bug has been marked as a duplicate of bug 896013 ***

Note You need to log in before you can comment on or make changes to this bug.