Comment 12 for bug 1802005

Hi Chris,
thanks for your report, your workarounds are interesting.

> sudo usermod -a -G libvirt libvirt-qemu

Users that shall be able to connect to libvirt should be in the group "libvirt" which also is what the socket is on as group.
  srw-rw---- 1 root libvirt 0 Sep 18 12:25 /var/run/libvirt/libvirt-sock=
Now allowing "libvirt-qemu" = the user the guests are executed as to be in that group should only open up a security hole of someone exploiting qemu also being able to reach out to the libvirt service.
Is something else reusing "libvirt-qemu" that shouldn't use it?

> sudo usermod -a -G libvirt libvirtdbus

While I don't think the above is "right" this one is much more interesting.
The user "libvirtdbus" is installed by package bin:libvirt-dbus which is of src:libvirt-dbus.
And indeed it is not member of that libvirt group:
root@f:~# id libvirtdbus
uid=997(libvirtdbus) gid=997(libvirtdbus) groups=997(libvirtdbus)

It might be right that this is a bug on libvirt-dbus which should make it part of the "libvirt" group on it's postinst.
Questions from here:
- Is changing just that group enough to get things working?
  - if not why not, what does adding user libvirt-qemu to group libvirt giving you?
- If we open libvirt to libvirt-dbus "by default" which is what this change would do,
  then how is the access to libvirt-dbus arbitrated?

@mdeslaur - we had non-fun with socket permissions in the past (being too open) so I subscribed you to be aware of the discussion about "what if we let libvirt-dbus access it by default".

@Pitti - are you still on cockpit these days? If so are you (re-)using the libvurt-qemu user in a way I didn't expect? If so could you outline how so we can find a middle ground working fine but being safe?