Comment 57 for bug 156085

On Fri, 2008-09-05 at 07:41 +0000, Martin Pitt wrote:
> shouldn't change anything. If the user can access those USB devices on
> the host, then he should equally be able to access them on the guest,
> since the kvm process runs under his user account and thus can use the
> ACLs?

The problem is, the user *doesn't* have permissions to the raw device
nodes - they've always been root:root. See Matt's explanation about raw
versus cooked.

On Fri, 2008-09-05 at 08:32 +0000, Matt Zimmerman wrote:
> On Fri, Sep 05, 2008 at 07:41:02AM -0000, Martin Pitt wrot
> KVM is something of a special case here.

KVM, Qemu, VirtualBox, and I suspect some other less well-used
hypervisors. I'm hoping we can find a generic solution so that
hypervisor packages don't conflict.

> For KVM USB pass-through, however, it needs access to the raw USB device
> (/dev/bus/usb/*/*) so that it can be presented as a virtual device to the
> guest OS.

Yes, this is the crux of the issue.

> Perhaps the raw device node permissions should be set to be the same as the
> cooked ones? This would at least avoid tweaking for devices recognized by
> the kernel.

Which cooked ones are you thinking about, Matt? From what I can see the
cooked group/permissions are mostly target-specific (e.g. block, video,
serial) whereas what the hypervisor needs is one group to cover all
device classes.

> Alternatively, we could punt and say that USB pass-through requires root
> privileges or manual tweaking of the device node permissions. I'm not sure
> to what extent this feature is used in typical KVM usage; I would think it's
> mostly useful for reverse engineering and such.

My experience, from watching the number of frustrated users posting in
forums on and off Ubuntu, is that there is a growing number of
non-technical users expecting that a VM guest 'will just work' with
their devices (mice, cameras, tablets, scanners (especially), printers,
etc.), and using the deprecated work-around
in /etc/init.d/mountdevsubfs.sh and commenting out the 'magic' around
line 40.

This is true particularly when the guest is a Windows variant and their
purpose in using the Windows guest is to use the drivers to access a
device (esp. cameras, scanners and printers) that they find problematic
or unsupported in Linux.

This class of non-technical user:

* expect access to their USB devices in the VM guest the same as if it
were running on the the physical machine
* should not be using root access

The way hypervisors and VMs are promoted and talked about creates an
impression that this stuff should 'just work' - its not a small
corner-case away from the sever applications.

I have been trying to avoid a heavy-handed approach of some kind of
root-user proxy server - I can't see how that would be possible anyway,
since raw device access is required and we already have it but it 'would
be nice' to manage permissions so the VM itself isn't run as root.

Hence my suggestion of an optional generic package "vm-usb" that is a
depend or more likely, a recommends, of hypervisor packages like kvm and
whose only task is to install a udev rule that assigns a "vm" group to
the USB device nodes, and adds the group to the system.
How about a "trusted user device access" package that is more generic
than the "vm-usb" suggested, to cover other similar cases in the future,
with "vm-usb" as a virtual that depends on it?

If the raw device nodes in /dev/bus/usb/*/* are so unique in terms of
permissions then maybe this special-case is justifiable as a user-chosen
option (recommended but not a default package install) since it is
addressing a different scenario than the deprecated "plugdev" group?