Bug in XDG Base Directory Specification

Ryan Lortie desrt at desrt.ca
Thu Nov 27 12:32:02 PST 2014

hi Markus,

On Thu, Nov 27, 2014, at 15:03, Markus Raab wrote:
> There seems to be a bug in the standard. The specification states:
> "If, when attempting to write a file, the destination directory is
> non-existant 
> an attempt should be made to create it with permission 0700."
> When someone creates system-configuration for a non-existant directory 
> (e.g. "/etc/xdg", a subdirectory of it or any other path as given in 
> XDG_CONFIG_DIRS) it should be created with 0700 according this
> specification.
> This means that users cannot access it afterwards.

If you look up a bit from where you find that language in the
specification there are two sections dealing with each of 'data' and
'config', separately.  The language is similar both both, so I'll
arbitrarily choose 'config' to quote:


 * Default configuration files should be installed to
 $sysconfdir/xdg/subdir/filename with $sysconfdir defaulting to /etc.

 * A user specific version of the configuration file may be created in
 $XDG_CONFIG_HOME/subdir/filename, taking into account the default value
 for $XDG_CONFIG_HOME if $XDG_CONFIG_HOME is not set. 


Although it's not stated explicitly, there is an implication here that
applications will only ever "create" files relative to XDG_CONFIG_HOME
and that the ones in the system locations will only be "defaults" that
are "installed" (ie: not written to at runtime).

Note in particular for the 'data' case: quite a lot of people are
interested in moving toward a world where /usr is readonly, so it will
never be possible to create files in XDG_DATA_DIRS.

I'd be happy if we added language to make this point more explicit to
prevent further misunderstandings.

Does that help?


More information about the xdg mailing list