[libvirt] [PATCH 2/2] qemu_cgroup: allow access to /dev/dri/render*

[Ján Tomko]

On Thu, May 19, 2016 at 01:52:00PM +0100, Daniel P. Berrange wrote:
> On Thu, May 19, 2016 at 08:36:35AM -0400, Cole Robinson wrote:
> > On 05/19/2016 08:21 AM, Daniel P. Berrange wrote:
> > > On Thu, May 19, 2016 at 01:29:07PM +0200, Ján Tomko wrote:
> > >> Allow access to /dev/dri/render* devices for domains
> > >> using <graphics type="spice"> with <gl enable="yes"/>
> > >>
> > >> https://bugzilla.redhat.com/show_bug.cgi?id=1337290
> > > 
> > > Ignoring cgroups for a minute, how exactly does QEMU get access to
> > > the /dev/dri/render* devices in general ?  ie when QEMU is running
> > > as the 'qemu:qemu' user/group account, with selinux enforcing I
> > > don't see how it can possibly open these files, as we're not granting
> > > access to them in any of the security drivers. Given this, allowing
> > > them in cgroups seems like the least of our problems.
> > > 

I saw this more as "not denying access" instead of allowing access.
For dac/SELinux, if the user adds qemu to the video group/adds ACLs
or creates a SELinux rule for it (or the more realistic solution
mentioned by Cole), libvirt will not interfere. But it would deny "*:*"
devices, giving a "Permission denied" (which is also harder to debug
than the other two security measures)

> > 
> > The svirt bits can at least be temporarily worked around with chmod 666
> > /dev/dri/render* and setenforce 0. The cgroup bit requires duplicating the
> > entire cgroup_device_acl block in qemu.conf which is less friendly and not
> > very future proof. Seems like an easy win
> 
> There's a potential issue though with going down a path now which is not
> viable long term, which we then get stuck supporting for upgradability.
> eg if we start granting permission to use these devices to multiple QEMUs
> concurrently will we regret doing that later and have to break people's
> deployments to fix it properly.
> 
> Without sVirt integration though I'd suggest we don't really advertize
> this to users, as telling them to chmod / setenforce is not really a
> supportable strategy for usage in any case.
> 

I'm afraid we'll end up with:
1. 'add qemu to this group/acl'
2. 'run this setsebool'
Since I'm not sure how we could differentiate between QEMUs that can and
QEMUs that cannot access this shared resource.

Jan