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

[Lennart Poettering]

On Fr, 01.09.23 02:02, Christian Pernegger (pernegger at gmail.com) wrote:

> Am Do., 31. Aug. 2023 um 21:55 Uhr schrieb Andrei Borzenkov
> <arvidjaar at gmail.com>:
> >
> > 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.

Typically any RF kill buttons are attached to the main seat of a
laptop only, hence this assignment.

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

You cannot attach devices to multiple seats. You should be able to
assign the device to a different seat though.

> Or what about /dev/kvm? Why should only seat0 have the ability to use
> KVM? (It can't be attached to other seats, either.)

/dev/kvm is 0666 by default, except of some distros that depart from
that. Please contact them for help how they intend to manage access
there, but the uaccess logic is not it.

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

fb is obsolete. fb devices are still assigned to seats but no unpriv
access is granted.

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

Well, you can do lots of things. We ship defaults only. Feel free to
write udev rules that assign things to whatever you want them to be
assigned.

By default render devices are only accessible to local users on the
seat they are logged on to, not everyone else, since typically
resources on a graphics card are bounded, and it makes sense to give
access to users who also get access to the screen, because typically
that's how things work and people assume them to work: graphics render
services are used to bring stuff to screen. There's also a "render"
group set up to which users can be added which should always get
access.

Lennart

--
Lennart Poettering, Berlin