Comment 13 for bug 1890858

Hi Bertrand and thanks for joining in,
with your report that the isolated "network unix dgram," rule helps is great to confirm the "how to fix".
But as outlined before - since this doesn't reproduce for everyone - we'd need to find what the subset of people that hit this do to trigger it. Only then we can really add the rule.

I was (once more) trying to trigger this, but still it just doesn't happen.
# clean new Focal system after install from a cloudimg
$ sudo apt install libvirt-clients libvirt-daemon-system
$ virsh list --all
# works, no denial

I compared the strace that tommy provided in comment #6 with one on this clean system:
Tommy:
socket(AF_UNIX, SOCK_STREAM, 0) = 6
connect(6, {sa_family=AF_UNIX, sun_path="/var/run/libvirt/libvirt-sock"}, 110) = 0
getsockname(6, {sa_family=AF_UNIX}, [128->2]) = 0
write(6, "\0\0\0\34 \0\200\206\0\0\0\1\0\0\0B\0\0\0\0\0\0\0\0\0\0\0\0", 28) = 28
poll([{fd=6, events=POLLIN}, {fd=7, events=POLLIN}], 2, -1) = 1 ([{fd=6, revents=POLLIN|POLLHUP}])
read(6, "", 4) = 0

Comparison:
socket(AF_UNIX, SOCK_STREAM, 0) = 5
connect(5, {sa_family=AF_UNIX, sun_path="/var/run/libvirt/libvirt-sock"}, 110) = 0
getsockname(5, {sa_family=AF_UNIX}, [128->2]) = 0
write(5, "\0\0\0\34 \0\200\206\0\0\0\1\0\0\0B\0\0\0\0\0\0\0\0\0\0\0\0", 28) = 28
poll([{fd=5, events=POLLIN}, {fd=6, events=POLLIN}], 2, -1) = 1 ([{fd=5, revents=POLLIN}])
read(5, "\0\0\0$", 4) = 4

Here the "good case" got something back from the socket, and the "bad one" didn't.
The denial is on libvirt daemons side, so virsh (or virt-manager) tried to talk to it, but communication was blocked it seems. The strace is on the client and only sees that the receiving end doesn't get anything. From there the "bad case" is on an exit path (but that is virsh code and not libvirtd where the denial happened).

None of this yet explains why it happens to some users, but not others.
I also tried a B->F upgrade as some reported to see it then to no repro-luck :-/

All that still is just dancing around the symptom, as I outlined in comment #9 and #10 we'd need to have status of the services/sockets as well as a strace of the daemon (not the client) in the bad case to get towards some next steps.

In addition anything from your config might help, e.g. a tarball of /etc/libvirt/ maybe that will allow me to trigger and debug it. If you (or others) need help what exactly to debug, which commands to use please get in touch here and I can help.

For the sake of recognizing a pattern - are all of the affected seeing this on a 18.04->20.04 upgrade or are new installs affected as well? Also are all affected systems Desktop installs or are there Server/Cloud-images as well?

@Bertrand - Tommy didn't yet get to answer to these questions. I think you can now switch back to the bad state by removing that apparmor line that you added and restarting libvirtd.
If that is true could you help to answer these questions?