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

[Cole Robinson]

On 05/20/2016 03:54 AM, Ján Tomko wrote:
> 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)
> 

I agree with this, and the patch in general. Dave and Gerd confirmed that this
is expected to be a shared resource, so I think extending the cgroups
whitelist is going to happen eventually anyways.

The svirt/dac issues are real and we need to figure that out, but it's kind of
irrelevant at this stage; the word is out on this stuff and people are going
to find a way to enable it one way or the other. I've already had discussions
with 5 people this week about when support will be available in virt-manager.
Heck I know people were already using the qemu command line passthrough magic
to test GL with the qemu gtk frontend with older qemu. This is just one of
those features that people are going to want to play with, integration issues
be damned, so IMO better that we get out in front of it.

What I'm afraid of specifically with this cgroups issue is people will work
around it with a custom cgroup_device_acl, then some time later when we bump
the default list to make some new qemu feature work, suddenly that old cgroup
list doesn't cut it and the user get's weird errors with new qemu, which we
have to debug. svirt and dac workarounds are less scary in that regard

- Cole