[libvirt] Per-guest configurable user/group for QEMU processes
Daniel P. Berrange
berrange at redhat.com
Thu Feb 23 21:34:59 UTC 2012
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 :|
More information about the libvir-list
mailing list