[libvirt] [PATCH 05/12] Introduce a stacked security driver impl for QEMU

[Daniel P. Berrange]

On Wed, Jan 20, 2010 at 06:00:06PM +0100, Daniel Veillard wrote:
> On Wed, Jan 20, 2010 at 03:15:02PM +0000, Daniel P. Berrange wrote:
> > * qemu/qemu_conf.h: Add securityPrimaryDriver and
> >   securitySecondaryDriver fields to 'struct qemud_driver'
> > * Makefile.am: Add new files
> > * qemu/qemu_security_stacked.c, qemu/qemu_security_stacked.h: A
> >   simple stacked security driver
> > ---
> >  src/Makefile.am                  |    4 +-
> >  src/qemu/qemu_conf.h             |    2 +
> >  src/qemu/qemu_security_stacked.c |  353 ++++++++++++++++++++++++++++++++++++++
> >  src/qemu/qemu_security_stacked.h |   22 +++
> >  4 files changed, 380 insertions(+), 1 deletions(-)
> >  create mode 100644 src/qemu/qemu_security_stacked.c
> >  create mode 100644 src/qemu/qemu_security_stacked.h
> [...]
> > +++ b/src/qemu/qemu_security_stacked.c
> > @@ -0,0 +1,353 @@
> > +/*
> > + * Copyright (C) 2010 Red Hat, Inc.
> > + *
> > + * This library is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU Lesser General Public
> > + * License as published by the Free Software Foundation; either
> > + * version 2.1 of the License, or (at your option) any later version.
> > + *
> > + * QEMU stacked security driver
> > + */
> > +
> > +#include <config.h>
> > +#include <selinux/selinux.h>
> > +#include <selinux/context.h>
> 
>   Why do we need to include SELinux headers, the module content seems to
>   be agnostic on the underlying framework (SELinux/Apparmor)

Copy & paste error :-)

> 
> > +static int
> > +qemuSecurityStackedGenLabel(virConnectPtr conn,
> > +                            virDomainObjPtr vm)
> > +{
> > +    int rc = 0;
> > +
> > +    if (driver->securitySecondaryDriver &&
> > +        driver->securitySecondaryDriver->domainGenSecurityLabel &&
> > +        driver->securitySecondaryDriver->domainGenSecurityLabel(conn, vm) < 0)
> > +        rc = -1;
> > +
> > +    if (driver->securityPrimaryDriver &&
> > +        driver->securityPrimaryDriver->domainGenSecurityLabel &&
> > +        driver->securityPrimaryDriver->domainGenSecurityLabel(conn, vm) < 0)
> > +        rc = -1;
> > +
> > +    return rc;
> > +}
> 
>   Okay, so the general pattern is that any stacked driver call will fail
> if any of the subdriver entry point fail, a missing entry point not
> being a failure. I'm still surprized that if both entry point are
> missing we return 0 i.e. success...

If the operation being performed doesn't make sense for a driver it is
fine to skip it without error. This is actually the same semantics we
had before this refactoring, because the QEMU driver always checks for
NULL entry point & skips it without error.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|