On Sat, Jan 13, 2018 at 9:54 AM, <intrigeri+libvirt@xxxxxxxx> wrote:
> From: intrigeri <intrigeri+libvirt@xxxxxxxx>
>
> 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@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/libvir-list
--
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
