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

[Hans de Goede]

Hi,

First of all many thanks for your input!

On 09/19/2011 02:27 PM, Kay Sievers wrote:
> 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.

Yes, I already thought as much, but I wanted to be sure before rolling
my own solution.

> 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.

Well, that (open directly after applying acl) is the plan, so I don't
expect much trouble there. Is is safe to assume that apps listening for
udev events through gudev, won't see the event until udev itself is
done applying all rules? Or could there be a case where spice-gtk
gets the event for a new device, while udev is still applying acl's ?

> 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.

Right, I fully agree. But spice-gtk needs to run on multiple platforms,
which more or less automatically brings one to libusb ...

> If the asking process dies, ideally all is cleaned up automatically.

Yes, I do plan to take that into account, there won't be a daemon,
but a launch of a small suid helper each time device access is desired,
when its mother dies the helper will automatically remove the acl.

The plan atm is to:
1) spice-gtk launches the helper, sending it a bus + device number over
stdin
2) the helper does its thing, then sends ok / error over stdout
3) spice-gtk tells libusb to open the device, and when it has the
libusb_device_handle, closes stdin / stdout of the helper
4) on close of stdin the helper clears the acl and then exits

Since spice-gtk dying should automatically close all fd's it has open,
4) should happen automatically on spice-gtk dying

This is atm what I've in my head, I've no code yet, so please if you
want through shoot holes through this design, shoot now before I start
coding (likely tomorrow).

> 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.

Yeah, although that is a different topic from the passing it an already
open fd, the problem with the passing it an already open fd is that
that is not portable to win32 / Mac OS X, not that I plan to port
the policikit bits there, I'm talking from the libusb pov, and the
libusb people only want to offer features which they can support
cross platform (which makes sense).

Regards,

Hans