On Wednesday 05 December 2012 22:31:22 Thomas Kluyver wrote: > On 5 December 2012 22:14, David Faure <[email protected]> wrote: > > 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. > > /run/user was created for this use, though, so systems that don't have > $XDG_RUNTIME_DIR set probably won't have /run/user. My Ubuntu 12.04 > installation doesn't have either, while 12.10 does have both. And you can't > create a directory in /run, because it's not user-writable.
Right. And I just discovered that Debian unstable still has neither the env var nor the directory. But I really hope this is temporary... Does anyone know when Debian will set XDG_RUNTIME_DIR? > > 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 :-) > > I'm still not convinced that I am going too far. The runtime directory is > supposed to have a very precisely specified set of properties that > application authors can depend on. Silently (a stderr warning is all but > silent for GUI developers) falling back to a substitute that > *probably*offers *most* of the same features sounds like a recipe for hard > to find bugs and security holes. I think there's a real argument for > forcing application developers to think about the problem themselves. I have re-read the original discussion about XDG_RUNTIME_DIR, and the item about "must be cleaned up on logout" seems a bit secondary to me, and mostly to make things cleaner and simpler. http://lists.freedesktop.org/archives/xdg/2010-November/011694.html In other words, not really a security risk there. Using /tmp for user-specific session sockets is what we've been doing for decades, I don't think we should break apps just because the user's OS doesn't have yet the fancy new /run/user directory. > Also, while it's unclear how this will be used, I'm inclined to be > conservative. If consensus develops on a suitable fallback, I can add a > wrapper function to use it. But if I provide a fallback and later decide it > was a mistake, removing it would break a lot of code. I have to admit, that an application aborting due to no XDG_RUNTIME_DIR is exactly what made ubuntu implement it... https://bugs.launchpad.net/ubuntu/+source/weston/+bug/1029223 pushed https://bugs.launchpad.net/ubuntu/+source/pam-xdg-support/+bug/894391 to be implemented, it would seem. Strange that this behavior of "weston" didn't make debian do the same... -- 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
