[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH 2/2] security: Driver 'none' cannot create confined guests



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]