Great. I think it is a good approach. The lack of an enclosing tag still
bothers me. But, as you said, there's no serious problem not having it
and I can live with that :)
I believe the primary driver should be defined in qemu.conf, so I would
like to replace the "security_driver" config with two new configs:
primary_security_driver and additional_security_drivers. The last one
would contain a list of security divers separated by commas, for example:
primary_security_driver = "apparmor"
additional_security_divers = "dac,another_driver"
For device seclabel's, I intend to add a "model" attribute to specify
which security driver is being overriding (if it's not given, the
primary driver is considered).
<domain ...>
...
<devices>
<disk type='file' device='disk'>
<source file='/path/to/image1'>
<seclabel relabel='no' model='dac'/>
</source>
...
</disk>
<disk type='file' device='disk'>
<source file='/path/to/image2'>
<seclabel relabel='yes' model="selinux">
<label>
system_u:object_r:shared_content_t:s0
</label>
</seclabel>
</source>
...
</disk>
...
</devices>
<seclabel type='dynamic' model='selinux'>
<baselabel>text</baselabel>
</seclabel>
<seclabel type='static' model='dac'>
<label>501:501</label>
<imagelabel>501:501</imagelabel>
</seclabel>
</domain>
What do you think?
Regards,
Marcelo
On 02/23/2012 07:34 PM, Daniel P. Berrange wrote:
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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list