On 27.08.2012 16:14, Marcelo Cerri wrote:
Hi,
I was notified that the latest patches for libvirt DAC isolation is
causing some regression issues. I'm working on fixes for it but I have
some doubts of how I should handle some scenarios. I'd appreciate some
suggestions:
* Item 3.2: this is a test case that uses only SELinux driver, but
seclabels for both DAC and SELinux are dumped in guest's XML. Before my
patches, libvirt already made use of DAC driver when running in
privileged mode, but this wasn't reflected in guest's XML. I tried to
keep the same behavior and libvirt still adds DAC driver when running in
privileged mode, but I didn't realize this would impact in guest's XML.
So, I'm thinking about two alternatives:
1. Simply do not add the DAC driver when running in privileged mode.
2. Keep it as it is. Probably applications that parse guest's XML will
continue to run without problems if they just consider the first
security label.
Well, I'd say domain XML is supposed to grow over time and reflect new
features we add. So I vote for 2)
* Item 4.1: an error is issued because model is not defined for a
seclabel inside a device definition. model is used to differentiate each
label and should only be required when more than one security driver is
used. The problem here is related to the one in item 3.2, DAC was
implicitly added because libvirt is running in privileged mode and so we
have 2 drivers in use.
I can use the order that seclabels appears in XML to match with the
order that security drivers appears in qemu.conf to avoid this kind of
error. What do you think of this solution?
Works for me.
Michal
Regards,
Marcelo
--
libvir-list mailing list
libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list