[systemd-devel] Session-specific user services

[Mantas Mikulėnas]

On Fri, Apr 2, 2021 at 7:17 PM Arseny Maslennikov <arseny at altlinux.org>
wrote:

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20210402/800632aa/attachment.htm>