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

[Kay Sievers]

On Mon, Sep 19, 2011 at 15:13, Hans de Goede <hdegoede at redhat.com> wrote:
>> On Wed, Sep 14, 2011 at 16:17, Hans de Goede<hdegoede at redhat.com>  wrote:
>> 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?

Yes.

> Or could there be a case where spice-gtk
> gets the event for a new device, while udev is still applying acl's ?

Only one thing, there is no guarantee that there isn't another event
already queued/running in the window from getting the event to running
your code.

All udev events are for the same device are serialized. You get the
event only as the last action after all rules are handled. But events
can queue up.

I wouldn't expect any real world problems from this though. But it's
not entirely safe.

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

I see.

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

Right, sound fine.

The problem is fighting about the same ACLs for the user. It could be
that udev manages the ACLs for the same user at the same device. You
have races you can not really avoid here, because there is no
synchronization point. Again, it's probably not a real world problem,
but it's has the usual problems when two tools manage the same things.

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

Sounds all sensible. The thing that could come into your way is a VT
switch, and udev/systemd adding/removing exactly the same ACLs at the
same time.

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

I think it makes only sense if abstractions provide sensible
interfaces, which libusb doesn't for any hotplug capable code. Last
time I checked, it was completely inefficient, it scanned all the same
stuff over and over. And abstracting away the most powerful thing,
which is a file descriptor, might make cross platform happier, but
renders the lib pretty much useless for advanced Linux hotplug use
cases. There is really no reason libusb couldn't provide
libusb_get_device_from_fd() on platforms that support it. Your setuid
helper example will not really be portable to Windows anyway.

Honestly, all the stuff we need to invent here, like you mentioned
above with the ACLs, and in many other places where libusb is
involved, is just needed to work around the needlessly strict libusb
abstraction model.

In short, your planned code should work fine in the real world. But
ideally libusb should be fixed instead, to work sensibly in Linux
hotplug cases.

Kay