On Sat, 1 Oct 2022 16:18:43 +0300 Andrei Borzenkov <arvidjaar@xxxxxxxxx> wrote: > On 01.10.2022 15:46, Nils Kattenbeck wrote: > > I am logging in on a PC using SSH and need to access some peripherals > > which are attached to seat0. > > loginctl shows that my session is not attached to any seat: > > > > SESSION UID USER SEAT TTY > > 50 1000 septatrix pts/0 > > > > The devices are added to the seat using udev rules > > and I explicitly want to avoid making the device world read-/writeable > > or adding it to a group. > > Reading through the man pages for systemd-logind, pam_systemd etc > > did not lead me anywhere helpful but only confirmed the fact > > that virtual sessions are not assigned any seat by default. > > However I was unable to find information on how it is determined > > if a session is "virtual" or whether it can be configured for pam/logind/udev... > > pam_systemd first seat preference is XDG_SEAT environment variable so > you probably can somehow force it. But logind assumes seat0 has ttys and > session runs on specific ttyN so there could be unexpected issues with > session management (like activation/deactivation). > > logind sets device permissions for the currently active session on > seat0. Normally there is just one such session - session that is > attached to foreground tty. If you manage to force (multiple) ssh > sessions to also belong to seat0 and multiple users are logged in > concurrently - which session should logind use to set permissions? > > Also I am not sure logind can manage two multiple active sessions on the > same seat in the first place. I'm pretty sure logind can handle multiple sessions on the same seat just fine. The d-bus API has things like ActivateSession: https://www.freedesktop.org/software/systemd/man/org.freedesktop.login1.html That's how it is supposed to work on seats other than seat0, they won't have VTs to begin with. However, I would tend to share your scepticism on whether one can make it reasonably work on seat0 when VTs exist. The need to manage VTs on seat0 might be ingrained in logind. Theoretically, one might have better luck if VTs are disabled in the kernel, but of course lots of local console stuff is probably depending on kernel VTs and would break then - not give local access to the machine. A couple years ago I was looking at pretty much the same problem to help people who want to run Weston (a Wayland display server) via SSH and present to the machine's own monitor. I did not find any solution that would just work, aside from running everything as root and bypassing logind completely which I won't recommend to anyone, or using a systemd unit to start Weston which also requires root but doesn't run Weston as root. Nowadays libseat and seatd exist, which could be leveraged instead of logind, avoiding the policy checks that logind has. https://git.sr.ht/~kennylevinsen/seatd Of course, running two seat managers at the same time to control the same seat is perhaps not a good idea. I don't know how to solve the problem, but maybe these are some leads. Thanks, pq
Attachment:
pgpZd3pw73BGU.pgp
Description: OpenPGP digital signature
