Ubuntu
libvirt package

apparmor prevents using SCSI hostdevs

Bug #1573192 reported by Simon Déziel
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
libvirt (Ubuntu)
New
Undecided
Unassigned

Bug Description

Trying to pass a SCSI device from the host to a VM with this XML definition:

  <hostdev mode='subsystem' type='scsi' managed='no' sgio='filtered' rawio='no'>
    <source>
      <adapter name='scsi_host2'/>
      <address bus='0' target='0' unit='0'/>
    </source>
    <address type='drive' controller='0' bus='0' target='0' unit='0'/>
  </hostdev>

Results in Apparmor denials like this during the VM startup:

apparmor="DENIED" operation="open" profile="libvirt-65e0d1b9-f6b1-4926-8648-dc685778555a" name="/dev/sg2" pid=7904 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=111 ouid=111
apparmor="DENIED" operation="open" profile="libvirt-65e0d1b9-f6b1-4926-8648-dc685778555a" name="/dev/sg2" pid=7904 comm="qemu-system-x86" requested_mask="wr" denied_mask="wr" fsuid=111 ouid=111

Workaround:

Add "owner /dev/sg2 rw," to /etc/apparmor.d/libvirt/libvirt-$UUID and restart libvirt-bin.

Additional information:

# lsb_release -rd
Description: Ubuntu 16.04 LTS
Release: 16.04
# apt-cache policy libvirt-bin apparmor
libvirt-bin:
  Installed: 1.3.1-1ubuntu10
  Candidate: 1.3.1-1ubuntu10
  Version table:
 *** 1.3.1-1ubuntu10 500
        500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages
        100 /var/lib/dpkg/status
apparmor:
  Installed: 2.10.95-0ubuntu2
  Candidate: 2.10.95-0ubuntu2
  Version table:
 *** 2.10.95-0ubuntu2 500
        500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages
        100 /var/lib/dpkg/status

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: libvirt-bin 1.3.1-1ubuntu10
ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6
Uname: Linux 4.4.0-21-generic x86_64
NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
ApportVersion: 2.20.1-0ubuntu2
Architecture: amd64
CurrentDesktop: Unity
Date: Thu Apr 21 14:34:10 2016
KernLog:

SourcePackage: libvirt
UpgradeStatus: No upgrade log present (probably fresh install)
modified.conffile..etc.libvirt.qemu.conf: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/qemu.conf']
modified.conffile..etc.libvirt.qemu.networks.default.xml: [deleted]

See original description
Revision history for this message
Simon Déziel (sdeziel) wrote :
Simon Déziel (sdeziel)
description: updated
Revision history for this message
Simon Déziel (sdeziel) wrote :

This is reproducible on Trusty (after removing sgio='filtered' which isn't supported). The same workaround works as well.

Revision history for this message
ermac god (ermacgod) wrote :

Workaround in focal fossa lts
Example connect my blueray sata device to virtual machine

1) check device channel (in my case channel 2 and device sg5)
root@host:~# lsscsi -g
[2:0:0:0] cd/dvd ASUS BC-12B1ST 1.01 /dev/sr0 /dev/sg5

2) edit the file /etc/apparmor.d/libvirt/TEMPLATE.qemu end add line
owner /dev/sg5 rw,
owner /dev/sg5 k,

example content file /etc/apparmor.d/libvirt/TEMPLATE.qemu
#
# This profile is for the domain whose UUID matches this file.
#

#include <tunables/global>

profile LIBVIRT_TEMPLATE flags=(attach_disconnected) {
  #include <abstractions/libvirt-qemu>
  owner /dev/sg5 rw,
  owner /dev/sg5 k,
}

3) on vm xml add where 2 on value scsi_host2 correspond to previously command lsscsi -g
<controller type='scsi' index='0' model='virtio-scsi'/>
<hostdev mode='subsystem' type='scsi' managed='no' rawio='yes'>
 <source>
  <adapter name='scsi_host2'/>
  <address bus='0' target='0' unit='0'/>
 </source>
</hostdev>

Revision history for this message
Lucas Kanashiro (lucaskanashiro) wrote :

Thanks for taking the time to file this bug.

I am not able to reproduce this bug since I do not have an scsi device to test it. I am subscribing Christian, he might have a better idea on how to address this issue.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hi Ermac,
yeah as usual if one has a special case not covered by the automatism of libvirt/apparmor as outlined on https://ubuntu.com/server/docs/virtualization-libvirt section "Apparmor isolation" adding rules like that will help.
But that is limited to either global rules (valid for all guests, which means less than preferable isolation) or a lot of manual - and thereby error prone - work.

Thanks for making me re-visit this long open case (hi Simon btw).
Looking at it with todays POV I think it might be resolved if I'd ever get to implement bug 1677398.
That would put it after the realization of storage which should cover this as well I'd hope.
I'll add a hint there to recheck this bug in that regard once we have experimental code.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.