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