User is not added to kvm group when installing gnome-boxes

Bug #1767302 reported by Johon Doee on 2018-04-27
132
This bug affects 41 people
Affects Status Importance Assigned to Milestone
gnome-boxes (Ubuntu)
High
Unassigned
Bionic
High
Unassigned
Cosmic
Undecided
Unassigned
Disco
High
Unassigned
qemu (Ubuntu)
Undecided
Unassigned
Bionic
Undecided
Unassigned
Cosmic
Undecided
Unassigned
Disco
Undecided
Unassigned
systemd (Ubuntu)
Undecided
Unassigned
Bionic
Undecided
Unassigned
Cosmic
Undecided
Unassigned
Disco
Undecided
Unassigned

Bug Description

Installing gnome-boxes does not add the user to the needed kvm group.
This leads to the problem that it is impossible to start any system within gnome-boxes.

Gnome-Boxes throwes the error: CPU mode 'custom' for x86_64 kvm domain on x86_64 host is not supported by hypervisor

adduser <username> kvm solves that problem but how should an average user know that. Gnome-Boxes is not usable as of now.

Johon Doee (jodoee11) on 2018-04-27
affects: partman-auto (Ubuntu) → gnome-boxes (Ubuntu)
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnome-boxes (Ubuntu):
status: New → Confirmed
Scott M (sgmaurin) wrote :

This actually affected me after the upgrade to Bionic. It was working before that.
Adding myself to the kvm group has Gnome Boxes working again.
For those who are still "terminal leery" you can add the "Users and Groups" app from the Software store for a GUI approach. Open it and find the kvm group, then select the box to add yourself to it. Log off or reboot and Gnome Boxes should fire up.

I also added myself to libvirt, don't know if I needed to or not. I was already listed in qemu.

spm2011 (spm2011) on 2018-07-02
tags: added: bionic
Paul White (paulw2u) on 2018-07-02
tags: added: cosmic
Jeremy Bicha (jbicha) on 2018-09-16
Changed in gnome-boxes (Ubuntu):
importance: Undecided → High
Jeremy Bicha (jbicha) on 2018-09-16
Changed in qemu (Ubuntu):
status: New → Confirmed

It would usually add users that are part of the sudo group to the KVM group.
Are you a member of the sudo group or are we facing an issue that this logic is nor more working?

Matthew Ames (supermatt) wrote :

I've just installed gnome boxes into a virtual machine and checked by groups both before and after, and I'm not a member of the kvm group, despite being in the sudo group.

I can't do much more testing right now, but from my understanding of the issue when I raised it about 6 months ago, my guess would be that the logic isn't working.

I had to manually add myself to the kvm group to make gnome-boxes work.

I found the actual issue, thanks for all your feedback.

I was mistakenly KVM membership for libvirtd membership.

So what happens is the following:
1. gnome-boxes depends on libvirt-daemon, but not libvirt-daemon-system
   The latter would contain the system integration with services and users for libvirt.
   That would make the users in 'sudo' be a member of group 'libvirtd' and that would let you
   control libvirt which would then 'for you' would drive KVM (the user libvirt-qemu which it uses
   is a member of kvm group)
   The dependency to libvirt-daemon only brings the binaries, but not this integration
2. Now gnome boxes seems to try driving some things on its own. It uses libvirt bindings, but seems
   not to want the service.
   But it does not set

   qemu(-system-common) that adds the KVM group never added users to the group (not back to
   Xenial at least, I didn't check further)
3. gnome-boxes does not use the libvirt-qemu user that libvirt sytem integration would use.
   That is why you can not access /dev/kvm

The same is true for any user on the system, which is meant to be an administrators decision - matching your manual addition of the user to the group.

I'm not sure yet what to do about it yet, but at least we found and can think about it now.

Two solutions come to mind:
1. qemu-system-common could add users in sudo to group kvm (as we do with group libvirtd)
   That comes at the drawback of handing out that permission by default to more users
   than before.
2. gnome-boxes is not driving it the way it is intended through libvirt. It should either use it
   the same way (isolated to user libvirt-qemu which is allowed to reach KVM).
   Or it can use it's own user and would then want to make sure it has KVM membership.
#. If gnome-boxes is meant to work with the current desktops user, then this is the same as #1
   And if it is ok - security-wise - should be done in #1. If not acceptable security wise we
   should not do it in any package.

I'll try to get hold of the security Team this week to get an ack to add sudo users to group kvm being ok or not.

One more important thing to mention - even if we change the postinst to add you to group KVM.
Especially for desktop users (harder to re-login) you might still be affected by the current login context not directly getting the new group membership "to be effective" and therefore requiring a new login (see [1]).

[1]: https://lists.ubuntu.com/archives/ubuntu-devel/2018-August/040408.html

Marc Deslauriers (mdeslaur) wrote :

ACK from the security team, adding the sudo user to the kvm group is acceptable as we already to basically the same with the libvirtd group.

Thanks for the Ack Mdeslaur, Diff would be like:

--- a/debian/qemu-system-common.postinst
+++ b/debian/qemu-system-common.postinst
@@ -9,6 +9,11 @@ if [ "$1" = configure ] ; then
     fi
 fi

+# Add each sudo user to the kvm
+for u in $(getent group sudo | sed -e "s/^.*://" -e "s/,/ /g"); do
+ adduser "$u" kvm >/dev/null || true
+done
+
 # dh_installdeb will replace this with shell code automatically
 # generated by other debhelper scripts.
 #DEBHELPER#

The code around is actually all Debian, but permission handling around KVM were separate for quite a while. I think it makes sense for Ubuntu in any case, and maybe might for Debian as well - if yes I'll submit it there as well.

Jeremy Bicha (jbicha) wrote :

Thanks Christian for looking into this. Maybe GNOME Boxes itself could suggest that users log out then log back in. There's this bug which asks Boxes to be more helpful in cases like this:

https://gitlab.gnome.org/GNOME/gnome-boxes/issues/225

Could somebody give the PPA at [1] a try if that would achive what a gnome-boxes user would need?

Because if not - e.g. for the re-login then it might not be worth the upload.

[1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3417

To be clear I'm waiting on a confirm that this (PPA above) is of benefit before pushing any further.
Setting this bug to incomplete to reflect this.

Note: as a side project I'd want to make libvirt error reporting on the similar case (need user relogon to be able to access) a bit nicer and provide more helpful text to the user.
The same could be considered by qemu if /dev/kvm is group accessible, but the effective group is not yet matching. But those tasks have to wait until I find some time for them.

Changed in qemu (Ubuntu):
status: Confirmed → Incomplete

Suggested also to Debian via [1], but there the situation might be different (?polkit?).

[1]: https://salsa.debian.org/qemu-team/qemu/merge_requests/2

Jeb E. (jebeld17) wrote :

I can confirm Gnome Boxes (gnome-boxes) works properly again in Ubuntu 18.10 x64.
Gnome Boxes version 3.30.2-0dc83a95 from dl.flathub.org.

Changed in qemu (Ubuntu):
status: Incomplete → Confirmed
Jeb E. (jebeld17) wrote :

Christian, get Flathub for Ubuntu and install the Flathub/Flatpak version of Boxes.
https://flathub.org/home

Thanks Jeb.
With that in place, but no other confirmation on the PPA I think this is good for now.
I still pinged on my MP to Debian for consideration but the bug as reported here is incomplete for now (no clear action that we have to take for now).

Changed in qemu (Ubuntu):
status: Confirmed → Incomplete

The user logged in in Cosmic and later should get uaccess set on /dev/kvm
getfacl /dev/kvm
after login should show that.
That is from udev/systemd and should therefore handle permissions correctly even without qemu installed in recent Ubuntu versions.

I'd keep older versions as-is as changing permissions on SRUs has turned out painful too often.

A little summary for my bad memory:

- We were suggesting adding sudo users to kvm group in
  https://salsa.debian.org/qemu-team/qemu/merge_requests/2
- Systemd upstream has decided /dev/kvm is 0666 and open for all
  https://github.com/systemd/systemd/commit/b8fd3d82205f632ce001fade74fed287e1564a1a
- Debian has chosen to stick with 0660 + group root:kvm (we want that as well)
- systemd >=239-6 have taken over doing all of that:
  https://salsa.debian.org/systemd-team/systemd/commit/4fc3fa53bfa6e16ceb6cd312f49003839b56144a
  This is in >=Cosmic
- qemu in debian dropped the group creation and the chown code (as it is done by udev/systemd now)
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892945
  https://salsa.debian.org/qemu-team/qemu/commit/cb8737ef48a37eddf12ac199b46f9034273ba6d3
  Not yet released, will be in >= Disco
- tagging with uaccess should work much better for qemu://session
- see https://enotty.pipebreaker.pl/2012/05/23/linux-automatic-user-acl-management/ for general uaccess info in general
- The reason to consider the this older <Xenial "add all sudo to kvm" handling was this bug here
  but that should be covered by uaccess in Disco and later
- I was abandoning my PR with Debian based on that retriage of the case

If that is still/again an issue on >=19.04 (after we have qemu 3.1 there) please report
$ getfact /dev/kvm

Jeremy Bicha (jbicha) wrote :

Christian, are you saying that you don't intend to SRU a fix to Ubuntu 18.04 LTS?

Hi - Jeremy yes, not in qemu at least.

IMHO this is
a) a user configurable change (add user to kvm group) (so it isn't very high severity)
b) a fix in older versions is limited to gnome-boxes which

It makes no sense to do (b) for qemu as it works without it just fine.
The latter changes I mentioned are even better as they also fix gnome-boxes in newer Ubuntu versions (via the uaccess method in systemd 239-6 and later).

If it wants to add that we could do the suggested (very) old style "add all sudo users to kvm group on install" in gnome-boxes postinst then at least the fix would match the scope of the issue.

Thanks for pointing that out, let me properly mark the tasks to avoid further confusion.

Changed in qemu (Ubuntu Bionic):
status: New → Won't Fix
Changed in qemu (Ubuntu Cosmic):
status: New → Fix Released
Changed in qemu (Ubuntu Disco):
status: Incomplete → Fix Released
Changed in gnome-boxes (Ubuntu Bionic):
status: New → Confirmed
Changed in systemd (Ubuntu Bionic):
status: New → Invalid
Changed in qemu (Ubuntu Cosmic):
status: Fix Released → Invalid
Changed in qemu (Ubuntu Disco):
status: Fix Released → Invalid
Changed in systemd (Ubuntu Cosmic):
status: New → Fix Released
Changed in systemd (Ubuntu Disco):
status: New → Fix Released
Changed in gnome-boxes (Ubuntu Cosmic):
status: New → Invalid
Changed in gnome-boxes (Ubuntu Disco):
status: Confirmed → Invalid

That were quite some updates, but it shows
- the fix in >=Cosmic came in via systemd
- (at least atm) I do not intend to fix it in Bionic Qemu
- gnome-boxes in Bionic is affected and could get a fix (the suggested auto-adding of users to
  group kvm if you want that)

Jeremy Bicha (jbicha) on 2019-01-07
Changed in gnome-boxes (Ubuntu Bionic):
importance: Undecided → High
status: Confirmed → Triaged
lotuspsychje (lotuspsychje) wrote :

Solved on 18.04 with: sudo adduser 'user' kvm and rebooted

Doug B (ve3gob) wrote :

FYI: adduser <username> kvm solves that problem
nope. added myself and still no joy.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.