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?

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

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

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.

Best regards,
T.

Links:

[1] xdg-compat - Provide XDG Runtime Directories. Project website.
URL: http://tk-sls.de/ref/xdg-compat