On 04/26/2013 11:42 AM, Daniel P. Berrange wrote: > On Fri, Apr 26, 2013 at 11:16:14AM -0400, Laine Stump wrote: >> On 04/26/2013 04:52 AM, Daniel P. Berrange wrote: >>> On Thu, Apr 25, 2013 at 09:44:33PM -0400, Laine Stump wrote: >>>> We don't know exactly the names of the VFIO devices that will be >>>> needed (and due to hotplug, we can't ever assume we won't need them at >>>> all), so we just add an ACL to allow any vfio device - they all have >>>> the major number 244 (/dev/vfio/vfio is 244,0, and the /dev/vfio/n >>>> devices are up from there). >>> We do the correct labelling of the /dev/vfio/"N" device in the >>> security drivers, so we should be able todo the same for cgroups >>> device ACL. Allowing all "N" is not acceptable from a security >>> POV. >> Up until now there hasn't been any cgroup-related code in the security >> drivers, though. So where should this go? Do we need a new driver >> backend for cgroups? This would then mean that we need to have three >> tiers of security drivers rather than two. Or can it just be put in the >> DAC driver? > We manage perfectly well to configure ACLs for individual disks that > a VM is given without having to wildcard allow every single /dev/sdN > disk. That fact that you were able to make the security drivers label > the /dev/vfio/n devices correctly, shows that the information required > is available. So why can't you set the cgroups ACLs correctly here too ? > There's no need to move cgroups code into any security driver. >
Sorry, my brain combined the first and second sentences of your message, and understood that you wanted this to happen in the security driver. I'll look up what's done for disks. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
