Fwd: $XDG_RUNTIME_DIR

[David Faure]

On Wednesday 19 December 2012 22:41:41 Lennart Poettering wrote:
> On Wed, 05.12.12 16:21, David Faure (faure at kde.org) wrote:
> > On Monday 03 December 2012 12:00:07 Thomas Kluyver wrote:
> > > I'm thinking of adding support for $XDG_RUNTIME_DIR to PyXDG. However, I
> > > want to check how to handle the case where it isn't set. From the spec:
> > > 
> > > *If $XDG_RUNTIME_DIR is not set applications should fall back to a
> > > replacement directory with similar capabilities and print a warning
> > > message. Applications should use this directory for communication and
> > > synchronization purposes and should not place larger files in it, since
> > > it
> > > might reside in runtime memory and cannot necessarily be swapped out to
> > > disk.
> > > 
> > > *I've read a few discussions around Ubuntu's implementation of this, and
> > > the consensus appears to be that there is no standard directory that
> > > will
> > > reliably have the right properties. So, from 12.10, Ubuntu will ensure
> > > that
> > > XDG_RUNTIME_DIR is set by default.
> > > 
> > > Therefore, my thinking is to provide no fallback, so if the environment
> > > variable is not set, the Python variable will have a useless value too.
> > > Or,
> > > if implemented as a function, it would raise an exception. Applications
> > > that need to handle this case would then have to handle it themselves.
> > > Does
> > > that sound reasonable?
> > 
> > Not very convenient, to expect apps to implement themselves a fallback.
> > 
> > In Qt, I implemented this:
> > 
> > if XDG_RUNTIME_DIR isn't set, mkdir /tmp/runtime-$USER,
> > then ensure that it's owned by the user (otherwise bail out),
> > then chmod to 0700 (and if that fails, bail out).
> 
> Well, this is a DoS. You cannot use a guessable name in /tmp.

I see no other solution, as long as some distros don't set XDG_RUNTIME_DIR.
(and BTW /tmp/.X0-lock is just as guessable, and has always been used.)

When talking to Debian people about setting XDG_RUNTIME_DIR, they pointed out 
that another DoS attack is to fill up the partition containing XDG_RUNTIME_DIR 
(e.g. filling up your /run/user/$USERNAME), preventing other users from 
creating files under their own /run/user/$OTHERNAME. Is there a way to solve 
this?

Finally, a last issue that came up about XDG_RUNTIME_DIR (when talking to 
Debian people), was that it's not per-X-session ($DISPLAY), so logging in more 
than once will break. A solution is for each application using XDG_RUNTIME_DIR 
to create a subdir named after the DISPLAY, but it would have been nice if 
this was handled by the OS automatically.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5