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?
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
[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
Re: [systemd-devel] Bluetooth in a multiseat (via loginctl) setup
Hello again, shelving that multiple BT adapters idea for a moment, since that doesn't seem to be a supported configuration, more's the pity, the issue with GNOME seems to be that /dev/rfkill doesn't get the right permissions. It's tagged "uaccess" alright, the intention seems to be that (active) logged-in users get rw-, but this only actually works on seat0. If both seats idle at the greeter, gdm (or lightdm) gets rw- via ACL. If I login at seat0, that ACL is replaced by an identical one for my user, and the GNOME BT panel works. If I login at seat1 instead, nothing changes, there's still just the one ACL for the greeter's user (and obviously the GNOME BT panel is broken). Obviously I could just override the regular permissions via udev rule, give it to an "rfkill" group or something, but I'd rather do it properly. Kind regards, Christian Pernegger I login on seat0, my user gets r Am Mo., 28. Aug. 2023 um 15:12 Uhr schrieb Christian Pernegger < perneg...@gmail.com>: > Hello all! > > Sorry to bother a -devel list with my user troubles, but I don't know > where (else) to start. > > So, Ubuntu 22.04, multiseat setup automagically via loginctl. The only > thing I had to do extra was disable Wayland in gdm. Works beautifully. > Except for Bluetooth. > > I've one USB port (with an attached hub) attached to seat one. Thought I'd > just attach a dedicated BT dongle to that hub, done. Turns out BT adapters > don't show up in the output of loginctl seat-status at all, not the USB one > on the hub, not the (USB) one integrated into the mainboard. Looking at > them with udevadm they seem to be tagged correctly, AFAICT. > > In GNOME on seat1 it shows my (manually paired) BT keyboard in the system > dropdown menu, but when I open BT settings it says BT is off, no adapters > found. > In GNOME on seat0 the BT settings GUI works, but AFAICT shows the wrong > adapter. > > I'm thinking I may just have the wrong end of the stick entirely--how is > BT supposed to work with multiseat? Ideally each seat would be able to pair > and configure its own BT devices in the usual GNOME GUI. But maybe it's > more of a bluetoothd access control thing than a device assignment one? > > Anyway, would appreciate a few pointers, > > Kind regards, > Christian Pernegger > > > >
[systemd-devel] Bluetooth in a multiseat (via loginctl) setup
Hello all! Sorry to bother a -devel list with my user troubles, but I don't know where (else) to start. So, Ubuntu 22.04, multiseat setup automagically via loginctl. The only thing I had to do extra was disable Wayland in gdm. Works beautifully. Except for Bluetooth. I've one USB port (with an attached hub) attached to seat one. Thought I'd just attach a dedicated BT dongle to that hub, done. Turns out BT adapters don't show up in the output of loginctl seat-status at all, not the USB one on the hub, not the (USB) one integrated into the mainboard. Looking at them with udevadm they seem to be tagged correctly, AFAICT. In GNOME on seat1 it shows my (manually paired) BT keyboard in the system dropdown menu, but when I open BT settings it says BT is off, no adapters found. In GNOME on seat0 the BT settings GUI works, but AFAICT shows the wrong adapter. I'm thinking I may just have the wrong end of the stick entirely--how is BT supposed to work with multiseat? Ideally each seat would be able to pair and configure its own BT devices in the usual GNOME GUI. But maybe it's more of a bluetoothd access control thing than a device assignment one? Anyway, would appreciate a few pointers, Kind regards, Christian Pernegger
