Re: [multiseat] How to make automatic ACL creation via udev "uaccess" tag work for seats other than seat0?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am Do., 31. Aug. 2023 um 21:55 Uhr schrieb Andrei Borzenkov
<arvidjaar@xxxxxxxxx>:
>
> On 31.08.2023 19:22, Christian Pernegger wrote:
> There is no ID_SEAT, so this device [/dev/rfkill] ]belongs to seat0 by default.

It makes no sense for /dev/rfkill to belong to a specific seat,
though. GNOME at least assumes the user to have write access.
Note that while /sys/devices/virtual/misc/rfkill shows up in the
output of loginctl seat-status it cannot be attached to another seat
("Could not attach device: No such device").
Or what about /dev/kvm? Why should only seat0 have the ability to use
KVM? (It can't be attached to other seats, either.)


The dri/renderD??? device is automatically attached to the seat that
the dri/card? one is attached to (even though it isn't a child
according to the seat-status tree--funnily enough this does not happen
for the fb? device). It makes sense that the rendering bits of a card
should "belong to" the seat that has the outputs, the problem is that
this renders it inaccessible to the other seats, which it shouldn't. A
seat can access another seat's *rendering capabilities* just fine as
long as the permissions are set correctly.

Case in point, I have seat0 on a Radeon 6600, seat1 on a Zen 4
iGPU--permissions permitting, seat1 can use the dGPU for rendering as
well, AAA games included. You could argue that isn't desirable for
isolation reasons, but multiseat isn't a security measure anyway, it's
about sharing resources efficiently.


These devices have uaccess set because (all) logged-in users can, and
probably should, have access to them. Restricting them to a particular
seat may make sense for some devices, and some use cases, but it's not
a good default.

Which is why I'm asking, is there a way to make uaccess work across
seats? I'd go as far as to say this is a bug, at least for rfkill and
kvm.
I mean, the old-fashioned way, using the kvm, video, render, and
rfkill groups, works, but I like the idea of the uaccess tag
mechanism, it's more flexible, elegant (in theory).

Kind regards,
Christian Pernegger



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux