Discussion:
Session-specific user services
Add Reply
Arseny Maslennikov
2021-04-02 15:41:45 UTC
Reply
Permalink
Hi everyone!

Recently there's a trend for session-specific processes and services
(and even GUI apps, via `systemd-run --scope') to run as their own user
units on eligible systems/distros, to have a clean and controlled cgroup
hierarchy.

I've been looking at https://systemd.io/DESKTOP_ENVIRONMENTS/ and see no
answer to the following question: how can a process, e. g. gvfs-daemon,
know which logind-session is it run for (for example, to find out the
seat by session ID), if it's actually in a user service unit?
The libsystemd source for sd_pid_get_session(), which is used by gvfs as
of today, gives a hint that function won't work in that case, since a
user service process's /proc/self/cgroup does not contain
"session-XXX.scope".
Mantas Mikulėnas
2021-04-02 16:29:23 UTC
Reply
Permalink
Post by Arseny Maslennikov
Hi everyone!
Recently there's a trend for session-specific processes and services
(and even GUI apps, via `systemd-run --scope') to run as their own user
units on eligible systems/distros, to have a clean and controlled cgroup
hierarchy.
I've been looking at https://systemd.io/DESKTOP_ENVIRONMENTS/ and see no
answer to the following question: how can a process, e. g. gvfs-daemon,
know which logind-session is it run for (for example, to find out the
seat by session ID), if it's actually in a user service unit?
The libsystemd source for sd_pid_get_session(), which is used by gvfs as
of today, gives a hint that function won't work in that case, since a
user service process's /proc/self/cgroup does not contain
"session-XXX.scope".
I don't think most daemons need to know this? Polkit has already changed
its policy from allowing actions for specific active session, to allowing
them for the whole uid if it owns *an* active session.

Also, part of the trend includes not running more than one graphical
session per uid. So the daemon doesn't really need to ask, if there's only
one answer. (Note that stuff like $DISPLAY gets imported into systemd
--user's environment, to make it available to the services'
environment, and you can't make $DISPLAY have two values at once.)

And if the daemon did know "its" session, that sounds like it would make it
*less* useful with two sessions, because you would have no way to run a
second instance for the other session anyway.
--
Mantas Mikulėnas
Arseny Maslennikov
2021-04-02 17:54:05 UTC
Reply
Permalink
Post by Mantas Mikulėnas
Post by Arseny Maslennikov
Hi everyone!
Recently there's a trend for session-specific processes and services
(and even GUI apps, via `systemd-run --scope') to run as their own user
units on eligible systems/distros, to have a clean and controlled cgroup
hierarchy.
I've been looking at https://systemd.io/DESKTOP_ENVIRONMENTS/ and see no
answer to the following question: how can a process, e. g. gvfs-daemon,
know which logind-session is it run for (for example, to find out the
seat by session ID), if it's actually in a user service unit?
The libsystemd source for sd_pid_get_session(), which is used by gvfs as
of today, gives a hint that function won't work in that case, since a
user service process's /proc/self/cgroup does not contain
"session-XXX.scope".
I don't think most daemons need to know this? Polkit has already changed
its policy from allowing actions for specific active session, to allowing
Do you mean default policies as bundled by maintainers of software
upstreams? IIRC it's still possible to use session ID in rules.
Post by Mantas Mikulėnas
them for the whole uid if it owns *an* active session.
There's at least a use case to know if an active session owned by the
UID is present on seat X:
https://gitlab.gnome.org/GNOME/gvfs/-/issues/557
In short, if a USB storage drive is connected to a particular seat,
we'd like to only try automounting it on that seat, and not on a random
seat that wins a race condition.
Post by Mantas Mikulėnas
Also, part of the trend includes not running more than one graphical
session per uid. So the daemon doesn't really need to ask, if there's only
Yes, that's mentioned at the systemd.io link. That would be OK if non-graphical
simultaneous sessions are allowed as well, locally or remotely.
Post by Mantas Mikulėnas
one answer. (Note that stuff like $DISPLAY gets imported into systemd
--user's environment, to make it available to the services'
environment, and you can't make $DISPLAY have two values at once.)
And if the daemon did know "its" session, that sounds like it would make it
*less* useful with two sessions, because you would have no way to run a
second instance for the other session anyway.
Simon McVittie
2021-04-06 11:51:56 UTC
Reply
Permalink
Post by Arseny Maslennikov
There's at least a use case to know if an active session owned by the
https://gitlab.gnome.org/GNOME/gvfs/-/issues/557
In short, if a USB storage drive is connected to a particular seat,
we'd like to only try automounting it on that seat, and not on a random
seat that wins a race condition.
Consider this system:

uid 1000
\- login session 1 on seat 1
\- GNOME
\- login session 2 on seat 2
\- getty/bash
\- systemd --user
\- gvfsd process 11111
uid 2000
\- login session 3 on seat 3
\- GNOME
\- login session 4 on seat 4
\- getty/bash
\- systemd --user
\- gvfsd process 22222

(Note that this is already a bit silly because each of uid 1000 and uid
2000 presumably represents a person, and at any given time, that person
is physically sitting in at most one seat...)

If gvfsd is a `systemd --user` service, then there are two instances of it:
one for uid 1000, and one for uid 2000. It is *not* the case that there are
four instances of it, one per seat.

Now we plug a USB drive into seat 3, and another USB drive into seat 4.
Suppose both users have configured gvfsd to automount USB drives. What
we want is that uid 1000 does not mount either of the USB drives (even
if they have the necessary permissions), and uid 2000 mounts both of them.

You seem to be suggesting that the right logic is for each gvfsd instance
to run this pseudocode:

# Here get_login_session() is assumed to return non-null even if the
# process is a systemd --user service. Will it return 3 or 4 for
# uid 2000's gvfsd? It can only return one of those!
if this_process.get_login_session().seat == usb_drive.seat:
usb_drive.do_automount()

I don't think that's right, though: assuming get_login_session() is
deterministic, we will only automount *either* the USB drive on seat 3
*or* the one on seat 4, not both.

I think the logic we want in gvfsd is probably more like this:

for login_session in this_uid.get_login_sessions():
if login_session.seat == usb_drive.seat:
usb_drive.do_automount()
break

Or, perhaps even better:

# This time we want this to return null if this process is a
# systemd --user service
login_session = this_process.get_login_session()

if login_session:
# traditional D-Bus activation, or XDG autostart, or run in the
# foreground for development/debugging; responsible for only its
# own login session
if login_session.seat == usb_drive.seat:
usb_drive.do_automount()
else:
# systemd --user service, shared by all our login sessions
for login_session in this_uid.get_login_sessions():
if login_session.seat == usb_drive.seat:
usb_drive.do_automount()
break

either of which will do the right thing: uid 1000 will not automount either
of the USB sticks (even if they have permissions to do so), and uid 2000
will automount both of them.

smcv
Arseny Maslennikov
2021-04-06 13:51:10 UTC
Reply
Permalink
Post by Simon McVittie
Post by Arseny Maslennikov
There's at least a use case to know if an active session owned by the
https://gitlab.gnome.org/GNOME/gvfs/-/issues/557
In short, if a USB storage drive is connected to a particular seat,
we'd like to only try automounting it on that seat, and not on a random
seat that wins a race condition.
uid 1000
\- login session 1 on seat 1
\- GNOME
\- login session 2 on seat 2
\- getty/bash
\- systemd --user
\- gvfsd process 11111
uid 2000
\- login session 3 on seat 3
\- GNOME
\- login session 4 on seat 4
\- getty/bash
\- systemd --user
\- gvfsd process 22222
(Note that this is already a bit silly because each of uid 1000 and uid
2000 presumably represents a person, and at any given time, that person
is physically sitting in at most one seat...)
At any given time one or both sessions might be locked (and thus
inactive). Anyway, I wouldn't expect additional complexity that
explicitly forbids this scenario.
Post by Simon McVittie
one for uid 1000, and one for uid 2000. It is *not* the case that there are
four instances of it, one per seat.
Now we plug a USB drive into seat 3, and another USB drive into seat 4.
Suppose both users have configured gvfsd to automount USB drives. What
we want is that uid 1000 does not mount either of the USB drives (even
if they have the necessary permissions), and uid 2000 mounts both of them.
IOW, if we're a user service, query all the sessions and their seats and
look for the right seat in there.
I agree with you here, this is a solid approach.
Post by Simon McVittie
You seem to be suggesting that the right logic is for each gvfsd instance
# Here get_login_session() is assumed to return non-null even if the
# process is a systemd --user service. Will it return 3 or 4 for
# uid 2000's gvfsd? It can only return one of those!
usb_drive.do_automount()
I don't think that's right, though: assuming get_login_session() is
deterministic, we will only automount *either* the USB drive on seat 3
*or* the one on seat 4, not both.
usb_drive.do_automount()
break
# This time we want this to return null if this process is a
# systemd --user service
login_session = this_process.get_login_session()
# traditional D-Bus activation, or XDG autostart, or run in the
# foreground for development/debugging; responsible for only its
# own login session
usb_drive.do_automount()
# systemd --user service, shared by all our login sessions
usb_drive.do_automount()
break
This behaviour would make sense to me.
Post by Simon McVittie
either of which will do the right thing: uid 1000 will not automount either
of the USB sticks (even if they have permissions to do so), and uid 2000
will automount both of them.
smcv
Arseny Maslennikov
2021-04-06 16:02:37 UTC
Reply
Permalink
Post by Mantas Mikulėnas
one answer. (Note that stuff like $DISPLAY gets imported into systemd
--user's environment, to make it available to the services'
environment, and you can't make $DISPLAY have two values at once.)
Oh. There's a design problem here as well: if session-specific software
sets environment variables for user services, they are not removed from
the user manager env store when that session terminates.

Let's consider the following scenario:
1. A machine is booted up and is ready to establish user sessions.
2. User U logs in (maybe remotely, or locally on a VT/kmscon) and
establishes an XDG_SESSION_TYPE=tty session Id=1. A systemd --user
instance is launched.
3. Later on, user U logs into a graphical session Id=2 at a
seat on the machine. `systemctl import-environment DISPLAY
XAUTHORITY', etc. Some time afterwards user U logs out; session 1 is
intact, as well as the systemd --user instance; the now-defunct
DISPLAY is not expunged from the systemd --user environment
dictionary.
4. User U logs in into a graphical session Id=3 again, but with a
Wayland-based setup, e. g. to work around a bug. `systemctl
import-environment WAYLAND_DISPLAY', etc. The defunct DISPLAY is
still present in the environment!


The above was a brainstormed reproducer; I did actually encounter this
kind of bug IRL a couple of times this way.
I'd used GDM to log in to GNOME on Xorg, then logged out, then logged in
to Sway (a Wayland compositor/window manager), and some apps e. g.
telegram-desktop malfunction because they infer they're running in GNOME
from the GNOME-specific environment vars that were not unset on logout
from GNOME:

% systemctl --user show-environment | grep -i GNOME
DESKTOP_SESSION=gnome
GDMSESSION=gnome
GNOME_DESKTOP_SESSION_ID=this-is-deprecated
XDG_CURRENT_DESKTOP=GNOME
XDG_MENU_PREFIX=gnome-
XDG_SESSION_DESKTOP=gnome
_=/usr/bin/gnome-session

The _, most likely set by a unix shell, is especially funny. :)

The leaked values of XDG_CURRENT_DESKTOP and XDG_SESSION_DESKTOP also
break xdg-desktop-portal in the new session as well, etc. In short,
this is not robust enough and can break in a multitude of ways, most of
them unknown a priori.

To sum it up, if we use the user manager environment store this way,
there should be a way to automatically remove session-specific
environment vars from systemd --user when the respective session is
terminated.

Possible ways to fix:
* Per-session unit managers: this approach was discussed previously and
deemed hard to implement; unclear relationships between session units
and user units.
* Tie the systemd--user environment store entries to session IDs.
When logind emits org.freedesktop.login1.Manager.SessionRemoved on
/org/freedesktop/login1, remove environment variables tied to that
session.
* user-specific environment stores for graphical sessions in logind and
an opt-in mechanism (e. g. UseSessionEnvironment=yes) in unit files to
use them, API to modify/flush them (on the bus and via loginctl),
autoflush when the graphical session dies.
Not too hard to implement, basically 1 hash table per user.
A session starter would do
`loginctl import-environment XDG_CURRENT_DESKTOP'
instead of
`systemctl import-environment XDG_CURRENT_DESKTOP'
If I recall correctly, user managers already requires logind, so
that's not a problem.

I'm not opposed to writing a patch to fix this or just filing an issue
report, but wanted to discuss the general direction we'd like to take
here first.

Loading...