pam_systemd is documented as starting
systemd --user using
PAMName=, so it runs inside a dedicated PAM session.
pam_systemd has a special-case for
PAMName=systemd-user, so that starting
user@.service does not recurse infinitely or deadlock. (Also this process doesn't get put in a new session scope unit).
$ systemctl cat user@
Description=User Manager for UID %i
pam_systemd does not really work with features tied to the PAM session that vary based on the individual TTY.
Instead of Instead,
pam_group, software can use
logind interfaces to gain access to local device nodes. (This affects relatively few applications: display servers, sound servers, and optical media writers.)
logind uses ACLs to grant the logged in user to certain devices. As long as the PAM session is open, any process with that UID will be able to access them.
logind also has a DBus interface which allows one process of that user to open certain devices, intended for the display server e.g. X Windows. It has code to handle switching VTs, and multiple "seats" (groups of devices).