Comment 32 for bug 1890858

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

The puzzling bit here is that libvirtd is the service that is ran as root by systemd.
I'm not seeing why the kind of user that calls virt-manager/virsh would make any difference.
As the problem so far seemed to be on the service side.

And it still is for your log
Jun 8 14:59:20 notebook kernel: [ 467.626033] audit: type=1400 audit(1623157160.575:108): apparmor="DENIED" operation="bind" profile="libvirtd" pid=1246 comm="libvirtd" family="unix" sock_type="dgram" protocol=0 requested_mask="bind" denied_mask="bind" addr="@userdb-faa385c89baf9fdc10b8cd36f899a797"

That still is "libvirtd" so why would the user calling virsh matter for the service?

---

I tried to connect to libvirt in various cases
1. use Bionic -> works
2. upgrade to Focal -> works
3. have sssd to log in a domain user ...
   I had no AD config, so I used a ldap based sssd auth that the autopkgtests of sssd use.
   That allowed me to check on the usual steps needed here.

#3.1 log in a trivial user - permission error lacking "libvirtd" group

At first I got:
testuser1@ldap:~$ virsh list
error: failed to connect to the hypervisor
error: Failed to connect socket to '/var/run/libvirt/libvirt-sock': Permission denied

But that is expected as my user logged in via sssd has no group membership for "libvirt".
There is no apparmor denial as usually reported by others on this bug.

You (Robert) had not the "permission denied", but the apparmor related I/O error.

#3.2 libvirt checks on local users

After fixing my /etc/security/group.conf to apply "libvirtd" group
testuser1@ldap:~$ id
uid=10001(testuser1) gid=10001(testuser1) groups=10001(testuser1),117(libvirt),10100(ldapusers)

$ virsh list
error: failed to connect to the hypervisor
error: Failed to find user record for uid '10001'

Still not the reported apparmor issue, but due to the user not being revere mappable for libvirtd. That is because the daemon has not yet learned of the changed user setup.
Restarting libvirt is enough to have it pick that up.

$ sudo systemctl restart libvirtd

#3.3 Finally at the issue you all see

testuser1@ldap:~$ virsh list
error: failed to connect to the hypervisor
error: End of file while reading data: Input/output error

Jun 14 09:29:07 ldap.example.com kernel: audit: type=1400 audit(1623662947.357:174): apparmor="DENIED" operation="bind" profile="/usr/sbin/libvirtd" pid=3585 comm="libvirtd" family="unix" sock_type="dgram" protocol=0 requested_mask="bind" denied_mask="bind" addr="@userdb-5402976fa0b85f7da530b09e72db0f01"

Ok, let me try to break that down to reproducible minimal steps ...