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

[Marc-André Lureau]

Hi

What's the status with this patch? If I understand the discussion, it is
needed, but not enough. Now that SELinux has been fixed (both in f24/f25
now), I can see only the ACL left: setfacl -m u:qemu:rw /dev/dri/renderD128
+ this patch allows me to setup a system VM with virgl. (though tbh, I
would be fine restricting virgl to qemu:///session only)

thanks

On Sat, May 21, 2016 at 1:10 AM Cole Robinson <crobinso at redhat.com> wrote:

> 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
>
-- 
Marc-André Lureau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20161110/c6313fcb/attachment-0001.htm>