Author: anonym Date: To: The Tails public development discussion list Subject: Re: [Tails-dev] Persistent torrc [Was: Tails Server: updated plan
and GSoC!]
segfault: > anonym:
>> [...]
>> One thing to note about the mumble-server script is the "little
>> bind-mount trick" used to workaround Tor's AppArmor confinement. We
>> won't have that problem, I think. I did that so that all things we want
>> to make persistent for mumble-server lives in the same directory on the
>> persistent media, i.e. both Tor's HS bits, and mumble-server's data. We
>> certainly can do better by making these two separate, e.g. we make
>> /var/lib/tor/hs persistent and store all HS bits there, and then make
>> another directory outside of this persistent for the service
>> configuration/data bits.
>
> I ran into this problem today.
:)
> To make it possible to use both ephemeral
> services and persistent services at the same time, I can't simply add
> all services to /etc/tor/torrc and make it persistent, because then
> obviously all hidden services would be persistent. Sadly, we don't have
> /etc/torrc.d yet. So instead I chose to use the
> /usr/share/tor/tor-service-defaults-torrc for the persistent services
> and /etc/tor/torrc for the ephemeral ones.
I think you should immediately look elsewhere for a better solution.
tor-service-defaults-torrc must not be made persistent for the same
reasons torrc must no (e.g. new versions will change this file, which
persistence will "hide"). I don't even think this solution is wortwhile
to use temporarily while fixing other parts -- a main goal of this
project is to have a nice solution for this.
> I wrote some code to make single files persistent by creating a new
> directory in TailsData_unlocked, moving the file into it and adding the
> directory to the persistence.conf with type "link". I think this a
> pretty ugly solution.
It sounds ugly, indeed.
> Now the problem is that the AppArmor confinement doesn't allow Tor to
> use this symlink, because it points to a file outside of the allowed Tor
> directories.
ACK, this was the "big" problem I had to fight with when playing with
the mumble-server script.
> I could make the whole directory /etc/torrc or /usr/share/tor
> persistent, but this would make some other files persistent too. I think
> it would be problematic if a future release contains important changes
> on any these files. Actually, this would also be problematic if we only
> make one of the torrc files persistent and there would be important
> changes to it.
>
> I could make this persistence feature even more ugly by creating a
> subdirectory in /usr/share/tor/, making this subdirectory persistent,
> then creating a symlink to it to TailsData_unlocked, putting the
> tor-service-defaults-torrc in it and adding it to the persistence.conf
> with type "link" to link the tor-service-defaults-torrc to /usr/share/tor.
None of this is good enough, IMHO, and I don't think we have to dive in
to details why since there are good solutions.
> I think the best way would be to implement the torrc.d feature and/or
> the bind-mounting-regular-files feature.
Among these I think hacking our own torrc.d feature is preferable, but I
think there are a few other good solutions too:
# torrc.d hack
We have a wrapper that we *always* use to (re)start to, namely
restart-tor [0]. We could simply add logic to it so that before starting
tor, for each $line of all files in /etc/tor/torrc.d/*.conf, check if
$line is already present in /etc/tor/torcc, and if not, append $line.
It's not as refined as the upstream feature will be, but it'll serve our
purposes for now, so I think it is good enough.
# Maintain HiddenService{Dir,Port} lines in /etc/tor/torrc
This is very similar to the torrc.d hack above, but this logic is in
Tails Server instead. This is what the mumble-server script did,
essentially, and the availability of this option is what made me say "We
won't have that problem, I think" in the text you quoted from an earlier
email of mine above. No torrc persistence is needed for this -- Tails
Server's persistent configuration will contain all the parameters needed
for knowing exactly which HiddenService{Dir,Port} lines that should be
in /etc/tor/torrc. Therefore I think it's preferable to the previous option.
# add_onion
By using stem to communicate with Tor over the control port/socket to
add the hidden services, just like onionshare does (which would be a
good source for inspiration, code-wise), you don't need any torrc
persistence just like in the previous approach. This is probably the
most "proper" solution of these three (and requires implementing less
logic on our side), and it might even be the easiest after you've
familiarized yourself with the API. This seems like the best option to me.
