[RFC] XDG_RUNTIME_DIR

[Mikkel Kamstrup Erlandsen]

On 6 November 2010 23:03, Lennart Poettering <mzkqt at 0pointer.de> wrote:
> Heya,
>
> Ryan Lortie and I have been sitting down here at the GNOME Summit and
> have discussed an older proposal that was posted on the XDG ML by Ryan a
> while back, regarding definition of a directory where user applications
> can store runtime files and other file objects (sockets, ...) in. That
> directory should be machine-local, fully-featured (i.e. not on NFS) and
> its lifetime should be bound to the user actually being logged in. It is
> as such something like a per-user counterpart of /var/run.
>
> So, here's what we propose: some kind of session manager should set
> $XDG_RUNTIME_DIR for all user processes to a directory for which the
> following rules apply:
>
> - It is owned by the user and the user is the only one having write
> access to it
>
> - The directory may be deleted (and should be deleted) after the user
> fully logged off or the machine is shut down.
>
> - The directory is on a local file system, and not shared with other
> machines.
>
> - The directory is fully featured, i.e. the majority of file system
> features the OS provides should be supported on it. More precisely, on
> Unix AF_UNIX sockets, symlinks, proper permissions, file locking,
> sparse files, mmap, hard link count must be available. (It is in fact
> recommended to use tmpfs or something similar as backing file system)
>
> - Files in the directories may be deleted by the OS if they are older
> than 12h. If an app wants to make sure that files it creates shall
> stay around longer it should update the mtime at least every 6h, or
> alternatively set the file sticky bit on the file.
>
> - Applications making use of this feature which do not find
> $XDG_RUNTIME_DIR to be set, should fall back to some other directory
> providing similar capabilities, and print a warning.
>
> Why all this?
>
> Mostly to have a secure place where user applications may place their
> unix sockets for communication, so that peers can discover the path
> safely without having to set all sockets via env vars for all
> processes. This is particular important to allow socket based activation
> in the session.
>
> systemd already implements this logic mostly, and Ryan updated GLib
> accordingly, too.
>
> I am writing this mail as a bit of a heads-up, as I plan to update the
> XDG basedir spec accordingly soon to make this official and push that to
> git, unless there's greater opposition against this plan.
>
> Comments?

Hi,

As noted by many other, I'd find something like this highly useful.

A few comments/questions:

It's not totally clear from the discussions on this list, what kind of
items you intend to go in XDG_USER_DIR? As I read it we are mainly
talking sockets, fifos, pid-files and such. However what about stuff
with non-negligible size - downloads in progress, short lived caches,
etc. I unpack tonnes of source packages that I always forget to delete
- will XDG_RUNTIME_DIR be suitible for this?

Something about the garbage collection scheme triggers my complexity
alarm bell. Time based GC seems like something that might be tricky to
get right (both for the session manager, but maybe even more clients
will not take the nature of the GC properly into account when using
it). I'd rather like something more deterministic. "When there are no
file handles on a file it's deleted" - might be too aggressive, but is
definitely clear cut :-)

I heard mention of using it for mmap()ed files - but if the runtime
dir is on a tmpfs (and not swapped) that would seem to undermine the
value of mmapping it - or am I misunderstanding something?

Considering how this affects unit- and integration testing of the
modules I maintain, I see this as a double edged sword. I presume I
could set up a "sandboxed subsession" by simply overriding
XDG_RUNTIME_DIR and all my code would automagically use an alternate
session bus, and what other resources they need. However it might come
back to bite me because overriding XDG_RUNTIME_DIR would make
*everything* connect to an alternate subsystem, not just, eg., DBus.

What path do you propose for XDG_RUNTIME_DIR? I can think of many
possibilities - ~/.runtime, /var/users/$login/runtime,
~/.runtime/$session_specific_uid..?

-- 
Cheers,
Mikkel