Opened 5 years ago

Last modified 2 years ago

#11325 new defect

RFE: Adhere to XDB base directory specification

Reported by: jamielinux Owned by:
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: unspecified
Severity: Normal Keywords: tor-client xdg-compliance intro
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

As noted by a Fedora user [1], when running Tor as a regular user it creates "$HOME/.tor" instead of "$XDG_CACHE_HOME/.tor", which is advised by the XDG specification [2] for user-specific non-essential (cached) data. Would you consider adhering to this specification?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=968163
[2] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

Child Tickets

Change History (12)

comment:1 Changed 5 years ago by nickm

Keywords: tor-client xdg-compliance added
Milestone: Tor: unspecified
Priority: trivialminor

What would be the benefit of users to adopting this standard? What operating systems support it?

I'm not categorically opposed to "adhering" to this specification, but I'd like to know a bit more about what the point is supposed to be.

(XDG_CACHE_HOME would not be appropriate -- only some of the files are cache files. The "state" file, for example, is not cached information, and treating it as safe-to-delete would degrade security. The "keys" subdirectory may contain sensitive private keys, and the "lock" file goes wherever locks go.)

comment:2 in reply to:  1 Changed 5 years ago by jamielinux

Replying to nickm:

What would be the benefit of users to adopting this standard? What operating systems support it?

I believe all modern Linux distributions support use of this standard, but support is more application specific not operating system specific. Many software packages on Fedora read the XDG_* variables if they are available, while others ignore them completely.

I'm personally not all that fussed about this. The Fedora package is usually run as root anyway, in which case these data files are stored in /var/lib/tor.

The benefits usually expressed include:

  • more organized home directory
  • more predictable locations for user-specific application files
  • more flexibility for changing these locations (eg, the user can set custom XDG_* variables)

(XDG_CACHE_HOME would not be appropriate -- only some of the files are cache files. The "state" file, for example, is not cached information, and treating it as safe-to-delete would degrade security. The "keys" subdirectory may contain sensitive private keys, and the "lock" file goes wherever locks go.)

Hmm agreed. XDG_DATA_HOME I would guess to be a more appropriate place for all of the files. (One might consider splitting files between different XDG directories according to their nature, but this would actually make things more confusing rather than providing any benefit.)

comment:3 Changed 5 years ago by jamielinux

(Just to clarify. When I said "The Fedora package is usually run as root anyway", what I really meant was started by root user through "systemctl start tor.service" and tor then runs as a non-privileged user that owns /var/lib/tor.)

comment:4 Changed 5 years ago by nickm

Hm. I think this is going to remain in the current milestone, to indicate its "nice to have but not urgent" status, unless it actually is urgent or important for some reason not yet apparent.

If somebody does want to go and implement it, make sure that there's a migration path for users who put files at the old locations. Ideally, write the migration/interop plan first for review.

comment:5 Changed 5 years ago by rahulsundaram

I filed this ticket downstream with Fedora and Jamie was kind enough to forward it here. I am planning to write some patches but wanted to confirm here that it makes sense. I could use libxdg-basedir library which would add a dependency to that library or just do something similar independently.

The rough plan is as follows:

1) Write a patch that does the following:

On launch,

If configuration is system wide, leave it as it is.

If ~/.tor exists, move lock and state to $XDG_RUNTIME_DIR/tor with a fallback to /var/run/tor

Move the rest of the files to $XDG_CACHE_HOME/tor with a fallback to $HOME/.cache/tor

If no such directory exists write to the new locations directly.

2) Update man page
3) Update sample configuration files

Last edited 5 years ago by rahulsundaram (previous) (diff)

comment:6 Changed 5 years ago by rahulsundaram

Also similar handling for ~/.torrc to $XDG_CONFIG_HOME/tor with a fallback to ~/.config/tor

In case, you are wondering why bother doing all this, please read http://ploum.net/post/207-modify-your-application-to-use-xdg-folders

Last edited 5 years ago by rahulsundaram (previous) (diff)

comment:7 Changed 5 years ago by nickm

Hm. I don't like the "transition by default" thing. That means that if you ever run a version of Tor using this patch, you can't downgrade safely to an older version.

Maybe we need a compile-time option, or a runtime option?

comment:8 Changed 5 years ago by nickm

Also, 'state' doesn't belong in $XDG_RUNTIME_HOME ; it really needs to be persistent across sessions or else guard node security is lost. And private keys certainly don't belong in $XDG_CACHE_HOME ; there is no way to recover them from backup if they're deleted.

(I hope that distributions aren't going to try to XDG-ify Tor on their own, or else they're bound to mess this kind of stuff up.)

comment:9 Changed 5 years ago by rahulsundaram

A compile time option (enabled by default) would make the transition smoother. So that we can eventually transition over to new locations and deprecate the old ones. IIRC git (under Linux) does something similar. I can put the state and private keys in $XDG_DATA_HOME. Let me know if this sounds ok.

Also, I don't think any distribution is trying to apply XDG locally. So I wouldn't worry about that.

comment:10 Changed 5 years ago by rahulsundaram

Please let me know if you mind adding a depending on the library https://github.com/devnev/libxdg-basedir. (16k, MIT licensed). Used in Linux by various software components including the Awesome window manager

comment:11 Changed 5 years ago by nickm

I talked about this a little on the #tor-dev IRC channel today.

Probably, the best way to implement this in Tor is with a runtime option, with the compile-time option at most setting the default value. We'd want to split DataDirectory into several options: KeysDirectory, LockDirectory, DataDirectory, CacheDirectory, and maybe a few more. Then we could edit the users of "get_datadir_fname*()" to use one of these more specific functions.

This would help not only with the XDG case, but with other cases too.

I don't mind an *optional* dependency on libxdg-basedir, if it's cleanly implemented and doesn't have a history of bugs.

One wrinkle to consider is interaction with our seccomp2 sandboxing code: we need to precompute all the paths that we will ever open at startup time.

comment:12 Changed 2 years ago by nickm

Keywords: intro added
Severity: Normal
Note: See TracTickets for help on using tickets.