On 17/09/15 21:01, tilt! wrote:
> Hi,
>
> On 09/17/2015 10:12 AM, Roger Leigh wrote:
> > On 11/09/2015 02:33, Daniel Reurich wrote:
> >> We could either use $USER_$SESSIONID or $USER/$SESSIONID to implement
> >> multiple sessions per user.
> >
> > This is definitely possible. It would probably need some thought on
> > how to determine which "session" you are in when cleaning them up via
> > PAM or whatever. Especially since it's not tied to the PAM session.
>
> Sorry, i still don't get it. What session?

For an X Session (which is the scope of this use case), the client_id as
chosen by the X Session Manager.

- See https://en.wikipedia.org/wiki/X_session_manager and
ftp://ftp.x.org/pub/X11R7.0/doc/PDF/xsmp.pdf

That said, it should be general enough to cover any service that wants
to provide a session management capability.
>
> >> On 10/09/15 23:46, Roger Leigh wrote:
> >>> There's no technical reason for /run/$user to live under /run. It
> >>> could be just as easily live under /tmp (or /var/tmp). So you could
> >>> default it to use /tmp/$user or /tmp/xdg-runtime/$user or whatever
> >>> and make this the default.
> >>>
> >> Why not /var/run/xdg-runtime/$USER - it's a better place and more
> >> likely to have quota's enabled then /tmp
>
> Please do not consider $USER, as $USER could be a character sequence
> that is not filesystem-safe. libpam-systemd uses $UID which appears like
> a safe choice.

Apologies. I was using $USER as a general reference to the user and
didn't intend it to be taken as a suggestion to use the username which
as you point out is unsafe. You are of course quite right that the
correct user identifier should indeed be $UID
>
> > If it's in /var/run it's in /run by default since /var/run is just a
> > symlink to /run.
> >
> > If you meant /var/tmp, this won't be cleaned on reboot, while /tmp
> > will be. Given the emphemeral nature of the user session data, /tmp
> > is therefore preferable to /var/tmp.
> >
> >>> So my recommendation here would be to - place /run/user in a
> >>> subdirectory of /tmp - configure XDG_RUNTIME_DIR to use this
> >>> location either in a PAM module, or even by hardcoding the default
> >>> to use this location--the specification might not provide this
> >>> default, but an implementation certainly can.
> >>
> >> indeed, although I'd argue that /var/run/<something>/$USER or
> >> possibly /var/lib/xdg_runtime/$USER would be better then anything in
> >> /tmp.
> >
> > I think the expected lifetime of the data would make these locations
> > sub-optimal, as mentioned above.
>
> FYI, i am working on an implementation of XDG_RUNTIME_DIR at [1]
> that can be configured to whatever a site-maintainer finds suitable.
>
> The default rundir prefix i am using is "/run/xdg-runtime", and
> allowing site-maintainers to change the prefix as well as the naming
> scheme (which by default is "$prefix/$UID") are key features of my
> implementation.
>
> If rundirs are on non-volatile storage, my implementation can delete
> them at system shutdown (assuming an orderly shutdown is performed).
>
> The implementation so far manages to do without any form of PAM mofule
> or login-managing daemon process. It's my intention to keep it that way.

That's great, but don't create something that would rule out PAM or
login-managing daemon processes too.
>
> Speaking of "sessions", to be able to use it as an infix in the rundir
> name, my implementation would require a filesystem-safe identifier of
> a session to be made available to the per-user rundir-name-generator.
> $XDG_SESSION_COOKIE is apparently filesystem-safe, however, i wonder
> if that is the "session" we are talking about.

I think XDG_SESSION_COOKIE is more aimed at restoring the previously
saved session state on login, ie start up all the applications and get
them to exactly the same state as it was at when previous log-out
occured (assuming all the client applications actually save there
session state). This is something I've really wanted for a long time
from a Linux Desktop.

Regards,
    Daniel.
-- 
Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722