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@xxxxxxxxxxxx> > 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.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
