Bug 1043162 - libvirt cannot set security context on writable block device: unable to set security context '...' on '/dev/dm-X'
Summary: libvirt cannot set security context on writable block device: unable to set s...
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libguestfs
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Richard W.M. Jones
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: TRACKER-bugs-affecting-libguestfs
TreeView+ depends on / blocked
 
Reported: 2013-12-14 13:07 UTC by Richard W.M. Jones
Modified: 2016-04-26 16:52 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-04-26 15:37:10 UTC


Attachments (Terms of Use)

Description Richard W.M. Jones 2013-12-14 13:07:07 UTC
Description of problem:

I'm a member of the 'disk' group.  This means I am able to write
to block devices without needing to su to root.

However libvirt cannot set the security context on this devices,
meaning that tools like virt-builder and virt-resize don't work
when the user is non-root and trying to write to a block device.

For example:

$ virt-builder fedora-19 --output /dev/fedora/tmptesting 
[   0.0] Downloading: file:///home/rjones/d/libguestfs/builder/website/fedora-19.xz
[   1.0] Planning how to build this image
[   1.0] Uncompressing
[  29.0] Copying
[ 116.0] Opening the new disk
virt-builder: libguestfs error: could not create appliance through libvirt.
Try using the direct backend to run qemu directly without libvirt,
by setting the LIBGUESTFS_BACKEND=direct environment variable.: unable to set security context 'unconfined_u:object_r:svirt_image_t:s0:c328,c758' on '/dev/dm-7': Operation not permitted [code=38 domain=24]

Note that the copy operation is successful (which is copying
the data to the block device), but libvirt fails as soon as
we start up libguestfs on the block device.

Version-Release number of selected component (if applicable):

libvirt-daemon-qemu-1.1.3-2.fc21.x86_64

How reproducible:

100%

Steps to Reproduce:
1. Add yourself to the 'disk' group.
2. Try to write to a block device (success).
3. Try to use libguestfs on a block device (fails).
4. Set LIBGUESTFS_BACKEND=direct and try again (success).

Comment 1 Cole Robinson 2015-04-25 23:07:50 UTC
I'm pretty sure this is still an issue with latest libvirt, but can you confirm Rich?

Though I think things are working as expected here from libvirt's perspective. Even the the disk is writable by your user, libvirt wants to add the svirt label to ensure that other VMs can't access that disk while your VM is using it. If we can't make that guarantee (because svirt labelling failed, and selinux==enforcing), libvirt should error out.

The confusing thing here is that apparently being in the 'disk' group doesn't grant access to change selinux labels. I tried:

[crobinso@colepc ~]$ groups
crobinso mock devel qa devqa gss-eng-collab crobinso
[crobinso@colepc ~]$ chcon -t virt_content_t /dev/sdd1
chcon: failed to change context of ‘/dev/sdd1’ to ‘system_u:object_r:virt_content_t:s0’: Operation not permitted
[crobinso@colepc ~]$ su -
Password: 
[root@colepc ~]# chcon -t virt_content_t /dev/sdd1
[root@colepc ~]# restorecon -R -F -v /dev/sdd1
restorecon reset /dev/sdd1 context system_u:object_r:virt_content_t:s0->system_u:object_r:fixed_disk_device_t:s0

From libguestfs's perspective here it likely doesn't care about the svirt protection from access by other VMs, in which case there's ways to disable labeling for specific disk devices via the XML, but that likely comes with some corner cases.

But otherwise I think libvirt is correct here. Thoughts?

Comment 2 Richard W.M. Jones 2015-04-26 08:23:05 UTC
It still happens for me on Fedora Rawhide with

libvirt-1.2.14-2.fc23.x86_64

$ sudo lvcreate -L 10G -n tmptesting /dev/vg_trick_hdd
  Logical volume "tmptesting" created.
$ groups
rjones disk wheel dialout

$ ll /dev/vg_trick_hdd/tmptesting 
lrwxrwxrwx. 1 root root 7 Apr 26 09:20 /dev/vg_trick_hdd/tmptesting -> ../dm-4
$ ll /dev/dm-4
brw-rw----. 1 root disk 253, 4 Apr 26 09:20 /dev/dm-4

$ virt-builder fedora-21 --output /dev/dm-4 
[   1.0] Downloading: http://libguestfs.org/download/builder/fedora-21.xz
[   2.0] Planning how to build this image
[   2.0] Uncompressing
[  20.0] Resizing (using virt-resize) to expand the disk to 10.0G
virt-resize: error: libguestfs error: could not create appliance through 
libvirt.

Try running qemu directly without libvirt using this environment variable:
export LIBGUESTFS_BACKEND=direct

Original error from libvirt: unable to set security context 
'unconfined_u:object_r:svirt_image_t:s0:c721,c831' on '/dev/dm-4': 
Operation not permitted [code=38 domain=24]

Comment 3 Cole Robinson 2015-04-26 15:37:10 UTC
Then I don't think there's anything for libvirt to fix here. If disk ownership doesn't let an unprivileged user change the selinux label, svirt_t write access to a block device is going to be rejected by selinux policy.

So AFAICT your options are either: 1) run the VM without svirt (adding <seclabel type='none' model='selinux'/> to the VM), or 2) use root

So closing this bug for libvirt, but maybe you want to repurpose for libguestfs docs change or something


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