On Wednesday 05 December 2012 16:03:33 Thomas Kluyver wrote: > On 5 December 2012 15:21, David Faure <[email protected]> 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, [email protected], http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
