On Thu, Feb 23, 2012 at 06:38:45PM -0200, Marcelo Cerri wrote: > 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. We can just keep virDomainGetSecurityLabel()/virNodeGetSecurityModel as only ever handling the primary security driver. Then add some new APIs which are more general int virNodeGetSecurityModelCount(virConnectPtr conn); int virNodeGetSecurityModelList(virConnectPtr conn, virSecurityModelPtr models, int nmodels); int virDomainGetSecurityLabelList(virDomainptr dom, virSecuriyLabelptr labels, int nlabels); 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