From: intrigeri <intrigeri+libvirt@boum.org>

On startup libvirtd runs a number of QEMU processes unconfined such as:

  /usr/bin/qemu-system-x86_64 -S -no-user-config -nodefaults -nographic -machine none,accel=kvm:tcg -qmp unix:/var/lib/libvirt/qemu/capabilities.monitor.sock,server,nowait -pidfile /var/lib/libvirt/qemu/capabilities.pidfile -daemonize

libvirtd needs to be allowed to kill these processes, otherwise they
remain running.
---
 examples/apparmor/usr.sbin.libvirtd | 1 +
 1 file changed, 1 insertion(+)

diff --git a/examples/apparmor/usr.sbin.libvirtd b/examples/apparmor/usr.sbin.libvirtd
index a1083b0410..0ddec3f6e2 100644
--- a/examples/apparmor/usr.sbin.libvirtd
+++ b/examples/apparmor/usr.sbin.libvirtd
@@ -63,6 +63,7 @@
 
   signal (send) peer=/usr/sbin/dnsmasq,
   signal (read, send) peer=libvirt-*,
+  signal (send) set=("kill") peer=unconfined,
 
   # Very lenient profile for libvirtd since we want to first focus on confining
   # the guests. Guests will have a very restricted profile.
-- 
2.15.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Sat, Jan 13, 2018 at 9:54 AM,  <intrigeri+libvirt@boum.org> wrote:
> From: intrigeri <intrigeri+libvirt@boum.org>
>
> On startup libvirtd runs a number of QEMU processes unconfined such as:
>
>   /usr/bin/qemu-system-x86_64 -S -no-user-config -nodefaults -nographic -machine none,accel=kvm:tcg -qmp unix:/var/lib/libvirt/qemu/capabilities.monitor.sock,server,nowait -pidfile /var/lib/libvirt/qemu/capabilities.pidfile -daemonize
>
> libvirtd needs to be allowed to kill these processes, otherwise they
> remain running.

Hi intrigeri,
I recently had spotted this issue and discussed on IRC but couldn't
recreate after a while when I wanted to debug.
But the reason and the rule totally make sense.

It is a bit unfortunate as it allows random kills essentially, so if
anyone is up to we might be better up to spawn those capability
probers with a named profile that we can refer to here.
But until then the rule here is required to not get into awkward situations.

+1 from me, thanks intrigeri

> ---
>  examples/apparmor/usr.sbin.libvirtd | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/examples/apparmor/usr.sbin.libvirtd b/examples/apparmor/usr.sbin.libvirtd
> index a1083b0410..0ddec3f6e2 100644
> --- a/examples/apparmor/usr.sbin.libvirtd
> +++ b/examples/apparmor/usr.sbin.libvirtd
> @@ -63,6 +63,7 @@
>
>    signal (send) peer=/usr/sbin/dnsmasq,
>    signal (read, send) peer=libvirt-*,
> +  signal (send) set=("kill") peer=unconfined,
>
>    # Very lenient profile for libvirtd since we want to first focus on confining
>    # the guests. Guests will have a very restricted profile.
> --
> 2.15.1
>
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list



-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Christian Ehrhardt:
> I recently had spotted this issue and discussed on IRC but couldn't
> recreate after a while when I wanted to debug.

I've seen it the last few times I've started libvirtd.service on two
different Debian sid ("unstable") systems.

> But the reason and the rule totally make sense.

> It is a bit unfortunate as it allows random kills essentially, so if
> anyone is up to we might be better up to spawn those capability
> probers with a named profile that we can refer to here.

Yes, this would be ideal. Sadly, this requires C programming skills so
it's out of my league.

> But until then the rule here is required to not get into awkward situations.

> +1 from me, thanks intrigeri

Thanks :)

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Hi,
On Mon, Jan 15, 2018 at 07:43:56AM +0100, intrigeri wrote:
> Christian Ehrhardt:
> > I recently had spotted this issue and discussed on IRC but couldn't
> > recreate after a while when I wanted to debug.
> 
> I've seen it the last few times I've started libvirtd.service on two
> different Debian sid ("unstable") systems.
> 
> > But the reason and the rule totally make sense.
> 
> > It is a bit unfortunate as it allows random kills essentially, so if
> > anyone is up to we might be better up to spawn those capability
> > probers with a named profile that we can refer to here.
> 
> Yes, this would be ideal. Sadly, this requires C programming skills so
> it's out of my league.
> 
> > But until then the rule here is required to not get into awkward situations.
> 
> > +1 from me, thanks intrigeri
> 
> Thanks :)

Pushed now.
 -- Guido

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list