[systemd-devel] Using systemd/udev acl management to open up additional /dev nodes on request

[Kay Sievers]

On Wed, Sep 14, 2011 at 16:17, Hans de Goede <hdegoede at redhat.com> wrote:
> Currently when people want to use usbredirection to a virtual machine from
> spice-client, they must launch the spice-client as root so that it can
> access device nodes under /dev/bus/usb.
>
> Since the purpose is for usbredirection to just work plug and play for
> virtual machines, this needs to change.
>
> My plan is to write a (privileged) helper program which will:
> 1) Check if it is invoked from a console session (using ConsoleKit
>   or the new ConsoleKit equivalent functionality in systemd in F-16)
> 2) Poke PolicyKit asking it if it is ok for the user to get access
>   to raw usb devices
> 3) Do something to actually open up the device to the spice-client,
>   there are 2 options:
>   a) relax permissions (set an acl)
>   b) open the device node and hand over a fd, but since I'm using libusb
>   to access the device nodes this is not really an option, leaving only a.
>
> 3) Is a part where I've some systemd/udev questions about. Currently
> udev already does similar opening up of acl's for the active console
> user for things like soundcards, etc. I wonder if somehow I could hook
> into udev to make use of this for the usb device nodes (after having
> done the policykit tests?

There is currently no way to dynamically hook into udev's/systemd's
ACL management. Only udev rules files could be used, but that is not
appropriate for any dynamic assignment.

You can set the ACLs yourself, but they might get removed with the
next udev event, depending how the ACLs are managed. This is currently
only safe, it the tool opens the device right after the ACL is
applied.

Fixing libusb to be able to act on a file descriptor sounds like the
ideal option. We really prefer dynamic settings to be bound to the
process that asks, and not stick dynamic settings to the filesystem.
If the asking process dies, ideally all is cleaned up automatically.

Libusb is pretty stupid in any hotplug context where the device in
question is already known, it scans all USB devices again and again
all the time. The last time I asked for any sane workaround anything
like that was refused though.

Kay