Fwd: $XDG_RUNTIME_DIR

[David Faure]

On Wednesday 05 December 2012 16:03:33 Thomas Kluyver wrote:
> On 5 December 2012 15:21, David Faure <faure at kde.org> wrote:
> > 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).
> > 
> > At least this makes your framework easier to use, because it returns
> > something
> > that works out of the box, in normal circumstances, without requiring the
> > user
> > or the distro to prepare the directory and set an env var...
> 
> Thanks David, that's useful perspective.
> 
> I think the reason /run/user is used is that the XDG base directories spec
> requires stronger guarantees about file and directory lifetime than are
> provided by /tmp:
> 
> *The lifetime of the directory MUST be bound to the user being logged in.
> It MUST be created when the user first logs in and if the user fully logs
> out the directory MUST be removed. If the user logs in more than once he
> should get pointed to the same directory, and it is mandatory that the
> directory continues to exist from his first login to his last logout on the
> system, and not removed in between. Files in the directory MUST not survive
> reboot or a full logout/login cycle.*

OK, so /run/user/ is a better default, when available, than /tmp, I'll adjust 
my code. Thanks for pointing this out, it looks like I didn't take this into 
account.

> ...
> 
> *If $XDG_RUNTIME_DIR is not set applications should fall back to a
> replacement directory with similar capabilities and print a warning 
> message.*

Well, this part makes little sense to me. How is an application (or a 
framework, in our case), supposed to find out which directories will be removed 
at logout/shutdown time? All we can do is go for /tmp/runtime-$USER or 
something like that, and indeed warn about the fact that a proper runtime dir 
wasn't found.

> So the question is, how similar do the capabilities need to be for a
> fallback directory? And what kind of warning is needed? I can fire a
> warning using Python's warnings mechanism from within the library, but in a
> typical GUI application that will be completely invisible.

Yes IMHO a warning means on stderr. The end user couldn't really be bothered, 
this is more about telling developers / sysadmins / powerusers about the 
situation being suboptimal.

> Providing a built-in fallback certainly makes life easier for application
> developers, but it could also lead them to overlook security issues,
> because the fallback doesn't have the same guarantees as $XDG_RUNTIME_DIR
> should. I don't think it's possible to offer the same guarantees without
> the OS managing the directory, in which case it will set the environment
> variable.

Right. Obviously the goal of all this is to make every unix set 
XDG_RUNTIME_DIR so that we don't have to do fallbacks. But as a transition 
measure, we might end up on unixes that don't set it, and therefore we need to 
do something. I don't believe that breaking completely (aborting) is better 
than creating a directory with proper permissions but improper life-cycle 
guarantees, and apparently the spec does agree with that statement.

I went too far in one direction (fallback without warning), you're going too 
far into the other one (no fallback), I think we should both do what the spec 
says: fallback, with a warning :-)

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