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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
