On Fri, May 20, 2016 at 09:54:29AM +0200, 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) > > > > > > > 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. We will have to figure this out somehow, becasue if usage requires those explicit admin steps outside of libvirt, then history shows the feature will be so painful to use that most people won't bother and those who try will file an endless stream of bugs. IOW without solving this problem, the feature might as well not exist for the majority of people. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list