Re: [systemd-devel] [multiseat] How to make automatic ACL creation via udev "uaccess" tag work for seats other than seat0?
On Fri, 1 Sep 2023 13:37:46 +0200 Lennart Poettering wrote: > On Fr, 01.09.23 13:13, Christian Pernegger (perneg...@gmail.com) wrote: > > > I don't know about this. Yes, seat1 could hog the GPU that seat0's > > outputs are attached to, or vice versa, but seat1 could just as well > > hog all the RAM or saturate the CPU. My point being, seats share the > > host's CPU power, RAM, ..., already, why not the rendering/compute > > power as well. IMVHO it's really just inputs and outputs that should > > be seat-specific. Restricting the shared resources available to a > > given seat, allocating them fairly, etc., is a different problem (and > > arguably one that I'd tackle per user and not per seat). > > CPU/RAM are by default resource managed, i.e. each user logged in gets > a similar amount under pressure, as controlled via the cgroups > logic. > > This is different from GPU resources, there's no such reosurce > management for that. If you mean cgroup resource limits for GPUs, yeah, it's not there yet, but I've seen people trying to add them. It just seems difficult to define what those resources are exactly and how to measure them in a sensible way, since GPUs have wildly different execution unit architectures. I'm not sure what the current patch state is. Thanks, pq pgp8gyq3kPyME.pgp Description: OpenPGP digital signature
Re: [systemd-devel] [multiseat] How to make automatic ACL creation via udev "uaccess" tag work for seats other than seat0?
On Fri, 1 Sep 2023 13:13:12 +0200 Christian Pernegger wrote: > Alright. I only played around with it in the hopes that it would help > me get some VTs (and VT switching) on seat1. So far, no luck on that > front. The funny thing there is that the kernel, where the VT is implemented, has no idea of any seat assignments. Seat management is completely a userspace invention. This can have some wild (security) consequences: https://gitlab.freedesktop.org/wayland/weston/-/issues/434 IOW, if seat0 is running only VT, you might have keyboards from *any* seat type into that VT *in addition* to any session running on that other seat. It's also common to assume, that only the default seat (seat0) can even have VTs. I don't see how you could have VTs on multiple seats, when the kernel simply has no concept of a seat. There is only one VT system, and that either takes input or does not (there is an ioctl for that). Individual input devices can only be excluded from the VT by opening and grabbing them, meaning nothing else can get them either. It would be best to forget the kernel VTs completely, and implement the equivalent in userspace, which can then be seat-aware and much more featureful (fonts, input methods) than the in-kernel VT can ever be. E.g. kmscon: https://wiki.archlinux.org/title/KMSCON Unfortunately looks like the original repository has been untouched for a decade now. Arch seems to be using this instead: https://github.com/Aetf/kmscon/ You might even want to aim for CONFIG_VT=n, in which case https://www.reddit.com/r/linux/comments/10eccv9/config_vtn_in_2023/?rdt=37727 might be interesting. Thanks, pq pgpBqMGXEm3d4.pgp Description: OpenPGP digital signature
Re: [systemd-devel] [multiseat] How to make automatic ACL creation via udev "uaccess" tag work for seats other than seat0?
On Fr, 01.09.23 13:13, Christian Pernegger (perneg...@gmail.com) wrote: > Of course, if you want to take the position that it's a bit weird for > GNOME to use /dev/rfkill to detect the presence of BT devices, I can't > argue against that. :) Doesn't NM/bluez manage these things from privileged code anyway? Is this really done from inside the GNOME UI with direct device access? > (From a use case perspective, it would be nice if paired BT devices > could somehow be tagged. I.e. so that each seat can pair devices and > manage them, but not see or manage ones paired by other seats and/or > users.) Yeah, it would be great if bluez would gain native multi-seat support, i.e. that it tracks seat assignments for paired devices. But that's something to request from bluez upstream, not systemd. > > You cannot attach devices to multiple seats. > > Roger that. Is there a way to exempt devices from the multiseat > mechanism, though? Mark them not seat-specific? Or is that > hard-coded? change the udev rules to not set the "seat" udev property on the relevant device. That's what decides whether seat mgmt is done for the device. > > You should be able to assign the device to a different seat though. > > systemctl attach won't let me, at least not using the path seat-status > spits out. But I'm sure the version of systemd in Ubuntu 22.04 is > ancient, and/or they may have done something to it. If you like, I can > try whether adding a udev rule manually works, but personally I'm not > too bothered about this particular issue. So the problem is that the rfkill device does not carry the ID_FOR_SEAT property right now, we only add that for pci/usb/… devices, i.e. the usual busses. rfkill being a virtual device doesn't carry that property. That property carries the string identifier that we should use for identifying the device for seat mgmt purposes. It's usually derived from the path ID of the device. To make rfkill managable via "loginctl attach" would mean adding such a property there. happy to take a patch for that, please submit via github. > > that's how things work and people assume them to work: graphics render > > services are used to bring stuff to screen. > > I don't know about this. Yes, seat1 could hog the GPU that seat0's > outputs are attached to, or vice versa, but seat1 could just as well > hog all the RAM or saturate the CPU. My point being, seats share the > host's CPU power, RAM, ..., already, why not the rendering/compute > power as well. IMVHO it's really just inputs and outputs that should > be seat-specific. Restricting the shared resources available to a > given seat, allocating them fairly, etc., is a different problem (and > arguably one that I'd tackle per user and not per seat). CPU/RAM are by default resource managed, i.e. each user logged in gets a similar amount under pressure, as controlled via the cgroups logic. This is different from GPU resources, there's no such reosurce management for that. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] [multiseat] How to make automatic ACL creation via udev "uaccess" tag work for seats other than seat0?
Am Fr., 1. Sept. 2023 um 11:48 Uhr schrieb Lennart Poettering : > > 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. If there's some form of physical RF kill button (dedicated, hard-wired keyboard shortcut, whatever), it makes perfect sense to assign that *button* to a specific seat. But /dev/rfkill, the rfkill *mechanism*, doesn't depend on the presence or absence of an RF kill button, does it? Just the presence of wireless hardware. You always have soft rfkill, don't you? (This particular box is a desktop without any physical RF kill buttons.) Of course, if you want to take the position that it's a bit weird for GNOME to use /dev/rfkill to detect the presence of BT devices, I can't argue against that. :) (From a use case perspective, it would be nice if paired BT devices could somehow be tagged. I.e. so that each seat can pair devices and manage them, but not see or manage ones paired by other seats and/or users.) > You cannot attach devices to multiple seats. Roger that. Is there a way to exempt devices from the multiseat mechanism, though? Mark them not seat-specific? Or is that hard-coded? > You should be able to assign the device to a different seat though. systemctl attach won't let me, at least not using the path seat-status spits out. But I'm sure the version of systemd in Ubuntu 22.04 is ancient, and/or they may have done something to it. If you like, I can try whether adding a udev rule manually works, but personally I'm not too bothered about this particular issue. > /dev/kvm is 0666 by default, except of some distros [...] Oh. I see. Sorry about that, then. > fb is obsolete. Alright. I only played around with it in the hopes that it would help me get some VTs (and VT switching) on seat1. So far, no luck on that front. > that's how things work and people assume them to work: graphics render > services are used to bring stuff to screen. I don't know about this. Yes, seat1 could hog the GPU that seat0's outputs are attached to, or vice versa, but seat1 could just as well hog all the RAM or saturate the CPU. My point being, seats share the host's CPU power, RAM, ..., already, why not the rendering/compute power as well. IMVHO it's really just inputs and outputs that should be seat-specific. Restricting the shared resources available to a given seat, allocating them fairly, etc., is a different problem (and arguably one that I'd tackle per user and not per seat). Anyway, thanks for getting back to me. Have a nice weekend! Christian Pernegger
Re: [systemd-devel] [multiseat] How to make automatic ACL creation via udev "uaccess" tag work for seats other than seat0?
On Fr, 01.09.23 02:02, Christian Pernegger (perneg...@gmail.com) wrote:
> Am Do., 31. Aug. 2023 um 21:55 Uhr schrieb Andrei Borzenkov
> :
> >
> > 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
Re: [systemd-devel] [multiseat] How to make automatic ACL creation via udev "uaccess" tag work for seats other than seat0?
Am Do., 31. Aug. 2023 um 21:55 Uhr schrieb Andrei Borzenkov
:
>
> 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
Re: [systemd-devel] [multiseat] How to make automatic ACL creation via udev "uaccess" tag work for seats other than seat0?
On 31.08.2023 19:22, Christian Pernegger wrote: Hello, still trying to get the kinks out of my multiseat setup ... AFAICT the proper way to give local users access to devices nowadays is via udev and the "uaccess" tag: devices with this tag set should automagically get an ACL entry that gives access to users with active sessions. This works brilliantly for seat0, but not for seat1 (and above, I presume). E.g. P: /devices/virtual/misc/rfkill N: rfkill L: 0 E: DEVPATH=/devices/virtual/misc/rfkill E: SUBSYSTEM=misc E: DEVNAME=/dev/rfkill E: MAJOR=10 E: MINOR=242 E: USEC_INITIALIZED=954210 E: SYSTEMD_WANTS=systemd-rfkill.socket E: TAGS=:systemd:uaccess:seat:shared: E: CURRENT_TAGS=:systemd:uaccess:seat:shared: There is no ID_SEAT, so this device belongs to seat0 by default. At login screens: # file: dev/rfkill # owner: root # group: root user::rw- user:gdm:rw- # *** [my emph.] group::rw- mask::rw- other::rw- Logged in on seat0: At login screens: # file: dev/rfkill # owner: root # group: root user::rw- user:chris:rw- # *** ["switches" to user] group::rw- mask::rw- other::rw- Logged in on seat1 instead: # file: dev/rfkill # owner: root # group: root user::rw- user:gdm:rw- # *** [sticks to gdm] group::rw- mask::rw- other::rw- This device belongs to seat0, so it is ignored when requested to change permissions for seat1. The GNOME BT control panel doesn't work unless the logged-in user has write access to /dev/rfkill, which is how I originally came across this. But it's the same for the /dev/dri/renderD* devices. The seat to which the matching card belongs has access some other way, but the other seat does not; if you do give both seats access, both can use both cards in vulkan applications, for example. I see there are other files under /dev that have the ACL "+", looks like it's the same for them. (I wonder if that's why I can't switch virtual consoles on seat1 even though fbcon is mapped to that.) Anyway, I know I can just override the permissions or use the old group way of doing things, but I'd prefer to fix things properly. The symptoms of wrong device permissions can be insidious. You need to assign your device to the correct seat.
[systemd-devel] [multiseat] How to make automatic ACL creation via udev "uaccess" tag work for seats other than seat0?
Hello, still trying to get the kinks out of my multiseat setup ... AFAICT the proper way to give local users access to devices nowadays is via udev and the "uaccess" tag: devices with this tag set should automagically get an ACL entry that gives access to users with active sessions. This works brilliantly for seat0, but not for seat1 (and above, I presume). E.g. P: /devices/virtual/misc/rfkill N: rfkill L: 0 E: DEVPATH=/devices/virtual/misc/rfkill E: SUBSYSTEM=misc E: DEVNAME=/dev/rfkill E: MAJOR=10 E: MINOR=242 E: USEC_INITIALIZED=954210 E: SYSTEMD_WANTS=systemd-rfkill.socket E: TAGS=:systemd:uaccess:seat:shared: E: CURRENT_TAGS=:systemd:uaccess:seat:shared: At login screens: # file: dev/rfkill # owner: root # group: root user::rw- user:gdm:rw- # *** [my emph.] group::rw- mask::rw- other::rw- Logged in on seat0: At login screens: # file: dev/rfkill # owner: root # group: root user::rw- user:chris:rw- # *** ["switches" to user] group::rw- mask::rw- other::rw- Logged in on seat1 instead: # file: dev/rfkill # owner: root # group: root user::rw- user:gdm:rw- # *** [sticks to gdm] group::rw- mask::rw- other::rw- The GNOME BT control panel doesn't work unless the logged-in user has write access to /dev/rfkill, which is how I originally came across this. But it's the same for the /dev/dri/renderD* devices. The seat to which the matching card belongs has access some other way, but the other seat does not; if you do give both seats access, both can use both cards in vulkan applications, for example. I see there are other files under /dev that have the ACL "+", looks like it's the same for them. (I wonder if that's why I can't switch virtual consoles on seat1 even though fbcon is mapped to that.) Anyway, I know I can just override the permissions or use the old group way of doing things, but I'd prefer to fix things properly. The symptoms of wrong device permissions can be insidious. Kind regards, Christian Pernegger
