10

I wanted to play a little bit with KVM on my Debian, and I installed the needed tools. The three groups showed up in the /etc/group file: kvm , libvirt and libvirt-qemu . What's the purpose of each of these groups?

For now I know that the libvirt group allows a regular user (via policykit) to connect to the libvirtd daemon without asking for root password, and hence it allows to create/remove/configure/manage of virtual machines.

I also know, that the /dev/kvm device has set the kvm group. What can a user do when he has read/write permissions to this device? Should I add a regular user to this group? If so, why?

I don't really know what's the purpose of the libvirt-qemu group. It looks like it's redundant, but many HowTos on the net suggest to add a regular user also to this group. Is this required?

Mikhail Morfikov
  • 10,309
  • 19
  • 69
  • 104

1 Answers1

7

See /usr/share/doc/libvirt-daemon/README.Debian: the libvirt group controls access to libvirt, through PolicyKit (as you determined), and libvirt-qemu is the user and group used to run system QEMU/KVM processes. You needn’t care about the latter, it’s an implementation detail, not a group end users need to be added to.

Membership of the kvm group grants access to /dev/kvm, which is necessary to run VMs using KVM. This is controlled using uaccess now, so the currently-active user on the console gets access automatically. libvirt-qemu’s primary group is kvm, which is how libvirt-managed VMs get access to KVM.

Stephen Kitt
  • 411,918
  • 54
  • 1,065
  • 1,164
  • I took me a while to figure out what `uaccess` is, but I think I got it. Basically, it's the `/lib/udev/rules.d/70-uaccess.rules` file, which has `SUBSYSTEM=="misc", KERNEL=="kvm", TAG+="uaccess"` . This tag `uaccess` is used by logind when a user logs into a graphical session to set permission to devices via ACL. When I checked `getfacl /dev/kvm` while logged in, I got `user:morfik:rw-` , and that's why a user doesn't have to be added to the kvm group (it's similar to video/audio). I think this is only true when systemd is used. – Mikhail Morfikov Jul 22 '20 at 16:10
  • Also I tested, what happens when the `uaccess` line is commented out and it looks like the virtual machines works well when there's no user access to /dev/kvm . So is it really required to give a user access to this file? – Mikhail Morfikov Jul 22 '20 at 16:12
  • I *think* `uaccess` also works without systemd, at least it worked on my system before I switched. Regarding access to `kvm`, since you’re using `libvirt`, the VMs run as `libvirt-qemu` and that user is a member of the `kvm` group. Users need access to `/dev/kvm` if they run VMs directly, *e.g.* by running QEMU directly, or if they use another tool which relies on KVM (for example, `dosemu2` in some configurations). – Stephen Kitt Jul 23 '20 at 12:05
  • In my system, there's no members in the kvm group. When I also commented out the uaccess udev rule, there was no user permissions set on the /dev/kvm device (checked via getfacl), and yet I was able to start my virtual machine via virt-manager as a regular user. So it looks like there was no access to the /dev/kvm device. – Mikhail Morfikov Jul 23 '20 at 12:29
  • 1
    Lack of access to `/dev/kvm` doesn’t make it impossible to run VMs, it makes it impossible to use KVM, I should have made that clear. Are you sure `libvirt-qemu` isn’t in `kvm`? What does `groups libvirt-qemu` output? – Stephen Kitt Jul 23 '20 at 12:38
  • Hmm, it looks like it is in the kvm group: `libvirt-qemu : kvm libvirt-qemu` . But shouldn't it be in /etc/group ? So what and how added it there? – Mikhail Morfikov Jul 23 '20 at 12:43
  • `libvirt-qemu`’s primary group is `kvm`, the link is in `/etc/passwd` (it took me a little while to figure that out ;-). – Stephen Kitt Jul 23 '20 at 13:10
  • I see it -- I have something like `libvirt-qemu:x:64055:136:` in /etc/passwd, and this 136 is `kvm:x:136:` in /etc/groups. – Mikhail Morfikov Jul 23 '20 at 13:18
  • I just tested what happens when I change 136 in /etc/passwd, to some other group number, and then I was unable to start VM via virt-manager :) So now I get it how this works. Thanks. – Mikhail Morfikov Jul 23 '20 at 13:25