Bug in XDG Base Directory Specification

[Markus Raab]

Hello List and XDG maintainers,

I implemented the "XDG Base Directory Specification" as stated in:
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
for Elektra 0.8.10 (yet unreleased), for information about Elektra see:
http://www.libelektra.org

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.

As an example, the user has XDG_CONFIG_DIRS set with "/etc/mydir". When
executing (lets assumed XDG_CONFIG_DIRS environment is preserved):

sudo kdb set system/key value

(kdb is the command-line tool for Elektra to get/set key/value pairs)

The implementation need to create the parent directories:

/etc/mydir
/etc/mydir/application/

with 0700 according to the specification. When a user then executes:

kdb get system/key

he/she won't be able to read the file below /etc/mydir/application/.

In conclusion: for directories below home, the 0700 as specified makes perfect
sense, but not for /etc.

Additionally, a problem is, that is not clearly stated that XDG_CONFIG_DIRS
have anything to do with configuration below /etc/, it could also point to the
home directory of the user, where a 0700 might be appropriate.

I think the behavior that fits best with the rest of the "XDG Base Directory
Specification" is that XDG_CONFIG_DIRS is intended to be system-paths
(including its default /etc/xdg) and those should be created with 0755 for
directories and 0644 for files.

What do you think?


best regards,
Markus

P.S. the correct spelling is existent and not existant

[Florian Müllner]

Post by Markus Raab
"If, when attempting to write a file, the destination directory is non-existant
an attempt should be made to create it with permission 0700."

It also states:
"$XDG_CONFIG_DIRS defines the preference-ordered set of base directories to
search for configuration files in addition to the $XDG_CONFIG_HOME base
directory."

So $XDG_CONFIG_HOME should always take precedence over any directory
defined in $XDG_CONFIG_DIRS, using the default $HOME/.config location if
the variable is undefined. A tool like kdb should read defaults from
$XDG_CONFIG_DIRS, but never write anything there.

[Markus Raab]

Hello,

Post by Florian Müllner
"$XDG_CONFIG_DIRS defines the preference-ordered set of base directories to
search for configuration files in addition to the $XDG_CONFIG_HOME base
directory."
So $XDG_CONFIG_HOME should always take precedence over any directory
defined in $XDG_CONFIG_DIRS, using the default $HOME/.config location if
the variable is undefined. A tool like kdb should read defaults from
$XDG_CONFIG_DIRS, but never write anything there.

In Elektra "normal" applications would use /sw/application to access their
configuration. In that case, files in $XDG_CONFIG_DIRS would be a fallback,
iff a key is not available in the namespace user/ (the feature is called
cascading), but every write attempt would be user/ (i.e. $XDG_CONFIG_HOME for
XDG). The XDG specification handles this simple case well.

The kdb-tool (or any Elektra based tool that does not use pathes that start
with /), however, is intended to give the admin full control over all the
system's configuration files. The admin can decide via the namespaces "user"
(e.g. user/sw/application), respective "system" (e.g. system/sw/application)
if he/she wants to configure a file for a specific user (in $XDG_CONFIG_HOME),
respective globally (for every user by modifications in /etc/).

From your argumentation I can conclude that the XDG specification simply does
not support full programmatical control over configuration files, but only
handles the simple consumption-case, i.e. when applications do not change
global defaults.

Positively said, I would argue that the XDG standard also does not prohibit
such endeavour, because the relevant phrases are "should" and not "shall"
and/or speak about "user-specific" and not about "system" configuration files,
e.g.: "There is a single base directory relative to which user-specific
configuration files should be written." and "should be made to create it with
permission 0700".

So the "bug" boils down to spelling and small clarifications as others already
noticed.

If XDG wants to go further and also want to standardize such tools, I am open
for discussions.

best regards,

[Ryan Lortie]

hi Markus,

Post by Markus Raab
"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?

Cheers