After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 328664 - Improve g_get_system_data_dirs and g_get_system_config_dirs
Improve g_get_system_data_dirs and g_get_system_config_dirs
Status: RESOLVED WONTFIX
Product: glib
Classification: Platform
Component: general
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2006-01-25 23:47 UTC by Behdad Esfahbod
Modified: 2011-02-18 16:14 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Behdad Esfahbod 2006-01-25 23:47:58 UTC
Background: I proposed this enhancement to the xdg list a few months ago, with no response: http://lists.freedesktop.org/archives/xdg/2005-March/006283.html

Proposal:

Treat the first empty component of the XDG_DATA_DIRS and XDG_CONFIG_DIRS lists as the default values, ie., /usr/local/share/:/usr/share/ and /etc/xdg respectively, and delete all other empty components.

Discussion:

This has two few advantages:

  * If the user does something like

    XDG_DATA_DIRS="/opt/share:$XDG_DATA_DIRS"

    things won't broke out of the blue.  Currently the line above does not do what the user expects, because if XDG_DATA_DIRS is not set or empty, it defaults to the default locations, but after setting it like this, the default locations are gone all of a sudden.  With my proposal, "/opt/share:" expands to "/opt/share:/usr/local/share:/usr/share".

  * Patches a security hole:  If the user sets XDG_DATA_DIRS like above, with an empty element, that may cause a security problem in applications that blindly append a path to the elements returned by g_get_system_data_dir, because, depending on how they do that, they will example /something/somefile or something/somefile.

Moreover, the proposal is not a violation of the basedir spec [1], because the spec says:

"""
$XDG_DATA_DIRS defines the preference-ordered set of base directories to search for data files in addition to the $XDG_DATA_HOME base directory. The directories in $XDG_DATA_DIRS should be seperated with a colon ':'.
"""

and an empty string is not a valid base directory.  So the proposed extension is only better handling of invalid XDG_*_DIRS variables.


I also find it awkward that the spec's default dirs have a final slash in their path.  That may confuse users of the api to assume that each element returned by g_get_system_*_dir ends with an slash.  I suggest guaranteeing that and make sure that all dirs have a final slash.

[1] http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html
Comment 1 Behdad Esfahbod 2006-01-26 00:07:53 UTC
In fact, the spec implicitly requires all elements of XDG_*_DIRS to have a final slash, since it says:

"""...Lookups of the data file should search for ./subdir/filename relative to all base directories specified by $XDG_DATA_HOME and $XDG_DATA_DIRS..."
Comment 2 Behdad Esfahbod 2006-01-26 00:09:09 UTC
One may argue that the spec is written so to allow looking at "." if you put an element empty.  But that's really weird, and a "." can always be allowed, by putting "./" in the list.
Comment 3 Matthias Clasen 2006-01-27 21:58:57 UTC
Sounds like a reasonable idea, but we need to get it reflected in the spec first, I think. 
Comment 4 Behdad Esfahbod 2006-01-27 22:05:04 UTC
I sent a link to this bug to the xdg-list again, and have CCed Waldo Bastian.  Hopefully I get some response this time, otherwise I don't know how this can be reflected in the spec...
Comment 5 Matthias Clasen 2006-01-27 22:19:17 UTC
You could just ask if anybody disagrees, and if not, go ahead and make the change.
Provided you have cvs access...
Comment 6 Waldo Bastian 2006-01-28 05:30:50 UTC
The correct solution would be to use
XDG_DATA_DIRS="$PREFIX/share:"${XDG_DATA_DIRS-/usr/local/share/:/usr/share/}

I'm reluctant to change the spec because many applications will need to be updated to incorporate new behavior. Having a trailing : imply a set of default directories is unprecedented to my knowledge and would replace one form of unexpected behavior with a slightly more advanced form of unexpected behavior.