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@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list