[systemd-devel] Session-specific user services

[Arseny Maslennikov]

On Fri, Apr 02, 2021 at 07:29:23PM +0300, Mantas Mikulėnas wrote:
> 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

Do you mean default policies as bundled by maintainers of software
upstreams? IIRC it's still possible to use session ID in rules.

> 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.

> 
> 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.

> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20210402/03f3dc57/attachment.sig>