On Tue, Feb 07, 2012 at 13:39:17 -0700, Eric Blake wrote: > On 02/07/2012 01:10 PM, Jiri Denemark wrote: > > In case the caller specifies that confined guests are required but the > > security driver turns out to be 'none', we should return an error since > > this driver clearly cannot meet that requirement. As a result of this > > error, libvirtd fails to start when the host admin explicitly sets > > confined guests are required but there is no security driver available. > > > > Since security driver 'none' cannot create confined guests, we override > > default confined setting so that hypervisor drivers do not thing they > > s/thing/think/ > > > should create confined guests. > > --- > > src/security/security_manager.c | 20 ++++++++++++++++++++ > > tests/seclabeltest.c | 2 +- > > 2 files changed, 21 insertions(+), 1 deletions(-) > > ACK that this fixes the issue, but I'm wondering whether we should move > the logic that rejects requireConfig out of security_manager.c and into > security_nop.c:virSecurityDriverOpenNop(). That is, the special casing > is a property of the 'none' security manager. Is it worth a v2 patch > that moves the error messages in that manner? That was my first thought but both defaultConfined and requireConfined bools are currently a property of security manager (not driver) and drivers have no access inside virSecurityManager. Moreover, virSecurityDriverOpenNop doesn't know whether it was requested explicitly or it was just the only available security driver when there was no explicit configuration. So while it is certainly doable I don't think it's worth all the mess it would require. Jirka -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list