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