Re: [PATCH 5/7] Add auditing of start/stop events to the QEMU driver

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

 



On Wed, Oct 27, 2010 at 04:55:10PM +0200, Daniel Veillard wrote:
> On Wed, Oct 27, 2010 at 03:48:59PM +0100, Daniel P. Berrange wrote:
> > On Wed, Oct 27, 2010 at 04:46:30PM +0200, Daniel Veillard wrote:
> > > On Wed, Oct 27, 2010 at 03:39:02PM +0100, Daniel P. Berrange wrote:
> > > > On Wed, Oct 27, 2010 at 04:33:03PM +0200, Daniel Veillard wrote:
> > > > > On Wed, Oct 27, 2010 at 12:36:15PM +0100, Daniel P. Berrange wrote:
> > > > > > Add audit hooks to report all start and stop events on QEMU
> > > > > > guest domains.
> > > > > > 
> > > > > > * src/qemu/qemu_driver.c: Audit start/stop events
> > > > > > ---
> > > > > >  src/qemu/qemu_driver.c |   59 ++++++++++++++++++++++++++++++++++++++++++++++-
> > > > > >  1 files changed, 57 insertions(+), 2 deletions(-)
> > > > > 
> > > > >   patch 1-4 trivial ACKs
> > > > > 
> > > > > One of the differences if we lock down in the driver (beside the
> > > > > redundancy that will be needed) is that we end up writing to the
> > > > > audit system deep in the driver with all the locks needed for operation.
> > > > > Is there a risk of being blocked while writing to the audit system ?
> > > > > This could potentially be a problem because all operations on the
> > > > > domain would be stopped during that time.
> > > > 
> > > > Quite possibly, but I believe audit people would describe this scenario
> > > > as a feature, rather than a bug :-)
> > > 
> > >   Grumpf ... :-(
> > > I'm fine with allowing code which can monitor/affect normal operation
> > > behaviour but it must be off by default then.
> > > There is no default set in daemon/libvirtd.conf for audit_level, I
> > > would like to see an assumed value of 0 then, is that the case ?
> > 
> > The default is that libvirt auditing will be enabled, if auditing is
> > enabled on the OS.
> 
>   Grumpf :-( , another randomization of the default behaviour of the
> library ... now each time we will have a bug reported, we will have to
> wonder if there isn't some audit rules doing some trick. At least it
> should now change the behaviour, it can just slow or stop operations
> on that domain,

I really don't think there's anything worth worrying about here. 
Auditing is only going to block in scenarios where you're already
doomed, like 100% disk full on /var/log

Daniel.
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.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


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]