Comment 37 for bug 1890858

Theory/Summary:
- the sssd login makes libvirt need to resolve a uid/gid as it isn't known locally
- once that worked it isn't re-done later on
- To resolve it it needs to bind a unix socket
  Jun 14 11:25:24 ldap.example.com kernel: audit: type=1400 audit(1623669923.999:144): apparmor="DENIED" operation="bind" profile="libvirtd" pid=47723 comm="libvirtd" family="unix" sock_type= "dgram" protocol=0 requested_mask="bind" denied_mask="bind" addr="@userdb-e87bdc7da8b5fabb4fbc28e32c4d783d"
- in Focal (not later and not before) that triggers an apparmor denial followed sometimes (depending on the setup) by a crash
- Allowing "network unix dgram," for libvirtd avoids the issue
- Many users have hit this various ways, but most likely all caused libvirt to look for UID/GID resolution that then was denied.

@Security - the question is if it would be ok to add the not further restricted "network unix dgram," rule to /etc/apparmor.d/local/usr.sbin.libvirtd in Focal.

As Jamie usually said it is very lenient anyway and therefore such things should not be a problem.
But better err on the side of caution, so I wanted to hear your input please.

P.S. If you happen to realize "oh yeah sssd login contexts in focal kernels are special because foo" let me know, but I fail to see why