Re: [libvirt] Per-guest configurable user/group for QEMU processes

On 02/23/2012 05:47 PM, Daniel P. Berrange wrote: >On Thu, Feb 23, 2012 at 05:41:27PM -0200, Marcelo Cerri wrote: >>Hi, >> >>I'm starting working on an improvement for libvirt to be able to >>support per-guest configurable user and group IDs for QEMU >>processes. Currently, libvirt uses a configurable pair of user and >>group, which is defined in qemu.conf, for all qemu processes when >>running in privileged mode. >> >>This topic was already commented in qemu mailing list (http://lists.nongnu.org/archive/html/qemu-devel/2011-10/msg00758.html) >>but, as this requires changes in libvirt API, I'd like to discuss >>what would be the best solution for it. >> >>A solution (as proposed in the link above) would be to extend the >>security driver model to allow multiple drivers. In this case, an >>example of the XML definition would be: >> >> ... >><seclabel type='dynamic' model='selinux'> >><label>system_u:system_r:svirt_t:s0:c633,c712</label> >><imagelabel>system_u:object_r:svirt_image_t:s0:c633,c712</imagelabel> >></seclabel> >><seclabel type='dynamic' model='dac'> >><label>102:102</label> >><imagelabel>102:102</imagelabel> >></seclabel> >> ... >> >>I don't know if this is a clean solution because the usual option >>would be to enclose the block above in a "<seclabels>" tag. But as >>this would break the actual API, it's not viable. > >While it is true that we would ordinarily have an enclosing tag >like<seclabels>, there's no serious problem not having it. Just >having two (or more)<seclabel> elements in a row is just fine, >given our backwards compatibility requirements. > >So I think this option is just fine. I agree that this is a good solution, considering the XML compatibility. But, what about virDomainGetSecurityLabel? It could access the first security label or ignore the DAC driver (and maybe another function could be added to access the whole list of seclabels), but it doesn't seem to be the best solution.