faure at kde.org
Wed Dec 5 14:14:14 PST 2012
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
> *If $XDG_RUNTIME_DIR is not set applications should fall back to a
> replacement directory with similar capabilities and print a warning
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
> 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
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
More information about the xdg