1️⃣4️⃣ Here's the 14th post highlighting key new features of the just published v260 release of systemd. #systemd260 #systemd
For a long time systemd-logind has known a concept we dubbed "uaccess" for managing access to device nodes in /dev/ based on which user owns the session currently in the foreground of a specific seat. (A "seat" is the combination of devices that interface with a human, i.e. a keyboard, a mouse, a screen, audio devices, and some more).
"uaccess" is a relatively simple concept I'd claim: in udev you "tag" a device with the "uaccess" tag (via TAG=), and it's device nodes automatically acquire managed ACLs that always give access to the UID currently owning the foreground session. And that's pretty much all there is to it.
Of course, this simplicity ended up being a bit too simple for some usecases. Specifically, modern graphics hardware typically separates the components that actually drive a display from those which do…
…the rendering, and on Linux this shows up as distinct devices, and separating these two classes for the purpose of device access actually makes sense too: if a user logs in via remote desktop functionality on a local system, it makes sense to give them access to the rendering device, but not the display hardware.
With systemd v260 there's now a mechanism in place to model this better: "xaccess", which takes inspiration from "uaccess" but tries to match this usecase better, …
… and at the same time establish a powerful new primitive.
Basically, "xaccess" operates with udev tags too, and also with login sessions, but instead it makes two changes: first of all there can be many xaccess tags and not just one: any udev tag with a name "xaccess-<suffix>" is considered an xaccess tag. And any registered logind session can get access to any group of devices tagged with such a tag, by setting the environment variable XDG_SESSION_EXTRA_DEVICE_ACCESS when…
… issuing the registration request to logind.
Or in other words: if gdm (or a similar display manager) wants access to render nodes for a remote session it manages, it just sets XDG_SESSION_EXTRA_DEVICE_ACCESS=render when registering it, and everything else then happens completely automatically and magically.
Lennart Poettering