On 10/09/15 23:46, Roger Leigh wrote:
> On 10/09/2015 12:11, tilt! wrote:
>>
>> Since i already use $HOME/.config for configuration data,
>> which more precisely is the default setting of XDG_CONFIG_HOME
>> (according to [1]), i would like to consider the pendant
>> XDG_RUNTIME_DIR for the tempfile i have described.
>>
>> Unfortunately, the specification [1] does not provide a default
>> for XDG_RUNTIME_DIR as it does for XDG_CONFIG_HOME.
>>
>> In Ubuntu, there used to be libpam-xdg-support (see [2]). It
>> sets up a directory in "/run/user", if neccessary, at login
>> time of the user. More recently, this task has been assumed by
>> pam-systemd (see [3]).
>>
>> Question open for debate:
>>
>> On a systemd-free system, should an alternative exist which
>> assumes the task of initializing XDG envvars as described by
>> [1] in the way done by [3]?
>
> This part of the XDG specification is pretty terrible. It's poorly
> specified, and the behaviour as specified is only implementable by
> systemd (i.e. its lifetime by refcounting all the logins/logouts). It
> also precludes having more than one session per user. By design... It
> wouldn't have required much effort to make this more flexible, but the
> authors of this "specification" don't generally bother with
> forward-looking flexible design.

We could either use $USER_$SESSIONID or $USER/$SESSIONID to implement
multiple sessions per user.
>
> 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

> [I argued for doing this originally, since /run/user would allow one to
> easily harm the system or other users by filling /run and/or /run/user
> depending on how the mounts are set up which would prevent other user's
> sessions and system services working properly, but I was told this was
> not a problem. And also, that /tmp could not be used because of
> tmpreaper. However, it's in reality another case of RedHat-specific
> constraints and workarounds being used to dictate policy. They have
> tmpreaper running by default, and don't have it set to ignore certain
> directories. In their world, this means using /tmp is an unreliable
> nightmare. However, using /tmp is entirely possible, and it's also
> possible even when tmpreaper is installed if it is configured
> appropriately (they considered this impossible...). Obviously
> configuring an optional service is preferable to a poorly-configured
> default influencing your system design, but very little these people do
> makes much objective sense.]

Yeah, well Redhat doesn't and shouldn't derive policy for us, and we
shouldn't be forced to submit to their braindead implementations either,
and if they won't play nice and co-operate on what are supposedly open
standards, then the it's not really an open standard anyway.
>
> 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.


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