torrc.d-style configuration directories
torrc.d-style configuration directories
Trac:
Username: aa138346
Activity
changed milestone to %Tor: 0.3.1.x-final in legacy/trac
added component::core tor/tor in Legacy / Trac intro in Legacy / Trac milestone::Tor: 0.3.1.x-final in Legacy / Trac owner::Jigsaw52 in Legacy / Trac points::medium in Legacy / Trac priority::low in Legacy / Trac reporter::aa138346 in Legacy / Trac resolution::implemented in Legacy / Trac severity::normal in Legacy / Trac status::closed in Legacy / Trac tor-03-unspecified-201612 in Legacy / Trac tor-client in Legacy / Trac type::enhancement in Legacy / Trac labels
One answer here might be to let other applications modify Tor's config without needing to learn how to modify the torrc file.
For example, we could imagine a 'tor-bridge' debian package that just adds a torrc.d/bridge-torrc file. Then you could become a bridge without needing a controller and without needing a text editor. We could also imagine a tor-relay deb.
Weasel, what do you think of this idea? Are debs like this a good idea, or is this approach bad precedent because it would bloat the number of total debs in the world too far?
It might also be useful for controllers like Vidalia on OSes where the Tor deb runs as a daemon and doesn't run as the user. In those cases we've talked about having Vidalia launch a script that prompts the user for her root password and then moves the new torrc file into place. Having it move its torrc into a Vidalia-specific name might keep things saner -- and might be doable without root if the torrc.d directory is owned by a group that the Vidalia deb puts the user into, as we might need to do to get ControlSocket going. On the other hand, ultimately it might instead just complicate the issue further once there are two controllers that each write their own config file.
If we do it, we'd want to sort out what to do if lines in different config files contradict each other.
-
{{{ | debs with just a single config file won't fly | also, files/dirs in /etc/ being user writable is obviously bad too. it's a privileged escalation attack waiting to happen | also, yes. conflicts are an issue | I still think it's a good idea tho. for instance the debian-defaults patch could just be a config file snippet then
|> in what way will they not fly? | ftp-master will never accept them | packages cause an overhead. for a single file that's probably too much overhead.
The specific reason I requested this functionality is because I want to be able to easily maintain a centralized list of rogue ExitNodes which can easily pushed out to other servers running tor. (See ticket legacy/trac#3143 (moved).)
But there are obviously other reasons why one might want to dynamically add/change configuration/performance options, while maintaining a base configuration. Some of these changes might even be made frequently.
Right now, I am just using the "-f" option with a simple script which assembles the new configuration to achieve what I want, but being able to dump everything into a directory would be great (either with a hard-coded torrc.d directory, or an include option).
Trac:
Username: aa138346
Actualpoints: N/A to N/A
Points: N/A to N/A-
From IRC:
> on tor-relays there is a person talking about the /var/run/tor/control file. am i correct in thinking this is something some package script makes, not tor itself? <weasel> arma: on 0.2.2.x debian packages, it's tor's control socket. > oh ho > does it go wherever $piddir is? <weasel> it goes to /var/run/tor. which is also where pid is. > perhaps this person who wants a tor config option for it is asking for a reasonable thing <weasel> it's not a config option. <weasel> that's because ControlSocket is something that tor's config stuff appends to rather than replaces. <weasel> and because tor doesn't do tor.d/* style configuration, so I have to patch the settings the package should have into the binaryhttp://archives.seul.org/tor/relays/Jul-2011/msg00024.html and http://archives.seul.org/tor/relays/Jul-2011/msg00025.html
Nick, perhaps this counts as the 'good application' you were looking for?
Quoting the Report from the "Tor ecosystem" BoF at DebConf 11 (http://archives.seul.org/or/dev/Jul-2011/msg00044.html):
We outlined some benefits that would have a
/etc/tor/torrc.ddirectory full of configuration snippets:- The 'tor' package will not (or less) need patches to change the default settings.
- It would make it much easier to implement example setups (relays, exit relays, bridges) either through a debconf question or through a system script like 'tor-setup-relay'.
- Tails developers will only need to drop a very small extra configuration file instead of having to rewrite the whole, which should ease development and reviewing.
- Other packages which need a hidden service to work (e.g. 'onioncat') would be able to create it automatically by installing the proper configuration snippet. That would enable them to work right after being installed.
The include directive was asked on legacy/trac#2863 (moved), btw - might be considered a duplicate.
Trac:
Cc: N/A to amnesia@boum.orgI am copying in here, what Nick said at the duplicate of this one (legacy/trac#8291 (moved)) and what I answered.
Replying to comment:2 nickm:
Some quick thoughts:
- Changing the default search path for torrc is probably not a great idea; it would break anybody who is using the current default location.
Changing from /etc/tor/torrc to /etc/torrc was indeed no good idea. Sorry for suggesting it.
Replying to comment:2 nickm:
- Having a tor.d directory is an okay idea. You'll need a fairly rigorous definition of what order the files in it are read, and how they interact with torrc and the defaults_torrc (if any). (Make sure you understand how the defaults-torrc logic works here before designing anything; make sure it can be reused.)
I think this way would be good:
defaults_torrc gets overruled by /etc/tor/torrc gets overruled by /etc/tor.d/10_something gets overruled by /etc/tor.d/20_somethingelse.
The same in other words:
defaults_torrc: lowest priority /etc/tor/torrc: normal priority /etc/tor/tor.d: highest priority
Sourcing /etc/tor.d/ in lexical order, i.e. first source /etc/tor.d/10_something, then source /etc/tor.d/20_somethingelse. If /etc/tor.d/10_something contains "CookieAuthentication 0" and /etc/tor.d/20_somethingelse contains "CookieAuthentication 1", then "CookieAuthentication 1" will win.
This is the way it usually works on Linux for folders such as /etc/profile.d, and the run-parts(8) tool works the same way.
Replying to comment:2 nickm:
- SAVECONF will need to treat definitions in /etc/tor.d as defaults, so that when it replaces torrc, it doesn't copy all of tor.d into torrc.
-
Trac:
Username: nguybao -
Patch file for feature legacy/trac#1922 (moved)
Trac:
Username: nguybao 
Quick notes:
- We don't use malloc; we use tor_malloc.
- We don't use free; see tor_free.
- Please use the same indentation style as the rest of Tor.
- strcpy? Please, no. We don't want heap overflows.
- In fact, please don't use strcpy in any other program that's supposed to be secure.
- Please no bubble sorts, insertion sorts, or other inefficient reimplementations of algorithms that are supposed to be O(n lg n). Just use smartlist_sort() or smartlist_sort_strings().
- Rather than hardwiring "/etc/", try using CONFDIR ?
- If we can't get FN_FILE from file_status(), why skip the file? Shouldn't we warn?
- Nothing in this code frees dirlist or its contents.
- Rather than making a fake command line and passing it to load_torrc_from_disk(), why not refactor the code into two functions: one to find the right configuration file, and the other to read and parse it. That way, this code could only send the second one.
Some more fundamental issues
- I thought that the semantics of options_init_from_string were that it replaced the current configuration with cf_defaults+cf. But that appears to means that, in this code, the original torrc file is completely replaced with the first file in /etc/tor.d/, then by the second, then by the third, and so on. (Is this tested?)
- It seems that for an ordinary Tor user, there's no way to override this stuff. If the system has an /etc/tor.d, I can't override those options even with "-f my_torrc", since the torrc is considered second, and the /etc/tor.d contents are considered last. There is no way to override that directory with another one, either. I don't think that can be the right way to do it, can it?
Trac:
Status: needs_review to needs_revisionReplying to nickm:
Some more fundamental issues
- I thought that the semantics of options_init_from_string were that it replaced the current configuration with cf_defaults+cf. But that appears to means that, in this code, the original torrc file is completely replaced with the first file in /etc/tor.d/, then by the second, then by the third, and so on. (Is this tested?)
I did not mean, if /etc/tor.d/10_something contains "CookieAuthentication 1" and /etc/tor.d/20_somethingelse contains no line containing "CookieAuthentication", that /etc/tor.d/10_something is completely disregarded. The idea was that configuration fragments are joined together in a predictable order. (Bao, please see above.)
- It seems that for an ordinary Tor user, there's no way to override this stuff. If the system has an /etc/tor.d, I can't override those options even with "-f my_torrc", since the torrc is considered second, and the /etc/tor.d contents are considered last. There is no way to override that directory with another one, either. I don't think that can be the right way to do it, can it?
This is a valid concern and no one considered that earlier. There is a solution.
At the moment in the Tor manual (man tor), there is...
-f FILE Specify a new configuration file to contain further Tor configuration options. (Default: $HOME/.torrc, or /etc/tor/torrc if that file is not found)
and...
--defaults-torrc FILE Specify a file in which to find default values for Tor options. The contents of this file are overridden by those in the regular configuration file, and by those on the command line. (Default: /etc/tor/torrc-defaults.)
I suggest adding..
--fragments FOLDER Specify a folder to contain further Tor configuration file fragments. (Default: $HOME/.tor.d, or /etc/tor.d/ if that file is not found)
This should allow an ordinary Tor user to override it.
Trac:
config.2.pch-
This needs more work than I can give it, but I should say some stuff:
- It would be a good idea to learn how to do safe string handling in C. strcat is just as bad as strcpy. I do not want heap overflows in tor.
- "/etc/tor.d" is still hardwired.
- It still uses a fake command line.
- It fails badly if smartlist_len(dirlist) is greater than CHAR_MAX. Why would you ever use a char for that?
- concatenating files is probably not the right approach.
These are just the basic issues; there are lots of comments and design discussions I made above that are still unfixed. I think this whole thing needs a total rewrite.
Trac:
Status: needs_review to needs_revision After bao no longer working on this... Anyone feel free to take this.
Trac:
Cc: amnesia@boum.org to amnesia@boum.org, adrelanos@riseup.net
Status: needs_revision to newRegarding the usefulness of this I would like to add: for creating a Tor centric Debian blend, the tor.d directory would be required. It would allow Whonix (or Tails in case they're interested, can't speak for them) to become a Debian blend.
Paul Wise (of Debian) said:
[...] The tor.d directory would need to be implemented before Whonix could become a blend. [...]
(Keep your time. There are probably other non-Tor specific deal breakers for creating a Tor centric Debian blend.)
I am creating a tor-bridge-relay Debian package in legacy/trac#10970 (moved) and this would be greatly appreciated.
Replying to infinity0:
An alternative method (Debian-only) is to modify the tor initscript to read /etc/tor/*.torrc and add the appropriate -f args. This would likely be easier to write and pass review than C code.
You make it sound really difficult. Is it? Would someone capable of C and remotely familiar with the Tor codebase need more than two hours for this small feature?
than to have tor decide the sort-order
This sounds complicated. Just do it the standard way, in lexical order.
The above patch is a refactoring that retains the same current behaviour. However, it makes future completion of this bug much easier. (I am already working on top of it.)
In order to implement multiple -f options, would be a 2-line diff on top of this patch. In order to implement a -d option would take some more effort. In both cases, some additional work is needed to make get_torrc_fname work properly, since that assumes we only ever read from one single torrc file.
edit: it looks like git-format-patch messed up the commit message formatting. :( hopefully it's still readable.
Trac:
tor.d.patchNick suggested this task as something useful to do at the Reykjavik hack day. Testing took me longer than it should have, but this patch changes options_init_from_torrc so that it:
-
Reads the torrc-defaults file, if any exists
-
Reads in lexicographic order all config files in the tor.d directory, if it exists. List options are cumulative across the files in this category.
-
Reads the torrc file, if any exists.
Comments and review welcome.
Trac:
Cc: amnesia@boum.org, adrelanos@riseup.net to amnesia@boum.org, adrelanos@riseup.net, NickHopper
Status: new to needs_review-
Replying to
[comment:32 nickm]:
Do your tests cover all the changed code?
No. In particular, the test cases added don't test the logic that checks for CONFDIR/tor.d. I couldn't think of an automated way to cover this with an unprivileged test process. Any suggestions? (I did test this in a VM with a setuid script)
-
Maybe have CONFDIR be an argument to the functions that use it, and write a unit test (a la the stuff in test_config.c) that tries it with a cooked value to replace CONFDIR when testing those functions?
Other quick notes:
- "make check-spaces" enforces some of our coding style rules
- Was there going to be a ~/.tor.d/ as well?
Trac:
tor.d.2.patchReplying to nickm:
Maybe have CONFDIR be an argument to the functions that use it, and write a unit test (a la the stuff in test_config.c) that tries it with a cooked value to replace CONFDIR when testing those functions?
OK, just added a new patch that has full branch coverage of the changed code.
- "make check-spaces" enforces some of our coding style rules
And makes this happy, too.
- Was there going to be a ~/.tor.d/ as well?
Is there a compelling reason to have this? I was thinking:
- A local install will change CONFDIR,
- if a user knows to make a ~/.tor.d/ s/he could also just pass -d ~/.tor.d But if there's a good reason, it's not hard to add.
Trac:
Cc: amnesia@boum.org, adrelanos@riseup.net, NickHopper to intrigeri, anonym, adrelanos@riseup.net, NickHopper-
Replying to Sebastian:
What's the status here? Is this likely to land in 0.2.6?
It well might. Somebody's got to review it and we've got to figure out whether it's the right behavior.
Trac:
Cc: intrigeri, anonym, adrelanos@riseup.net, NickHopper to intrigeri, anonym, adrelanos@riseup.net, NickHopper, tails@boum.orgTrac:
Cc: intrigeri, anonym, adrelanos@riseup.net, NickHopper, tails@boum.org to intrigeri, anonym, adrelanos@riseup.net, NickHopper