Comment 1 for bug 1890858

Hi Mike,
I'm more than happy to write a patch for this, but "Not Connected when they attempt to use virt-manager" isn't enough as that works fine for me and several other.

I'll need to be able to reproduce or at least consciously explain why the denial is happening to be able to extend the rules what is allowed.

Therefore I wanted to ask if you can reproduce that yourself, if you happened to find what makes a difference e.g. connect to a remote system and/or other configurations on that system?

Note - we already have these rules for unix sockets which cover the known cases

 50 # for --p2p migrations
 51 unix (send, receive) type=stream addr=none peer=(label=unconfined addr=none),
...
 64 # For communication/control to qemu-bridge-helper
 65 unix (send, receive) type=stream addr=none peer=(label=libvirtd//qemu_bridge_helper),
 66 signal (send) set=("term") peer=libvirtd//qemu_bridge_helper,
 67
 68 # allow connect with openGraphicsFD, direction reversed in newer versions
 69 unix (send, receive) type=stream addr=none peer=(label=libvirt-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*),
 70 # unconfined also required if guests run without security module
 71 unix (send, receive) type=stream addr=none peer=(label=unconfined),
...
126 unix (send, receive) type=stream addr=none peer=(label=libvirtd),

Therefore the question now is what is the use-case/setup detail we need to trigger this?