Re: [Tails-dev] Persistent torrc [Was: Tails Server: updated…

segfault:
> anonym:
>> segfault:
[...]
>>> 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.
>
> Right. Do you have any other idea to solve this problem of making single
> files persistent?

Yes, to implement the support for this properly in the persistence
back-end, in live-boot (which I believe mostly amounts to removing some
`[ -d ... ]` checks). I believe I've offered before to do that if
needed, otherwise, here's my explicit offer. :)

However, if possible, let's try an approach that doesn't rely on this,
ok? But I still guess you'd like to have this for the persistent
configuration/date for services (i.e. the non-Tails Server bits, e.g.
mumble-server's database and similar) as we've discussed before?

[...]
>> # 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.
>>
>> [0] config/chroot_local-includes/usr/local/sbin/restart-tor
>
> This way we would have to call restart-tor to add / remove a hidden
> service, right? So this would actually restart Tor, but right now I use
> "systemctl reload tor@default", which does not restart tor but still
> adds / removes hidden services. I think reloading provides better UX,
> because restarting Tor closes all circuits.

You're right! The easy solution would be to extract that part into a
reload-tor, which we'd call instead. Of course, restart-tor would also
call it, to get what I described above.

>> # 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.
>
> So you mean we shouldn't use the Tails persistence feature for this at
> all and simply ensure the lines are present when starting a Tails
> service, right? I didn't think about this before, but I think this would
> work.

Unless I have the wrong assumptions here. :) How I imagine this is that
Tails Server itself has a persistent configuration storing the settings
exposed by Tails Server for each service (is service X persistent?
autostart? and user options etc.). Probably we'd also store all
"persistent" hs keys here too. Beyond this, each service marked
"persistent" would have some directory for its persistent configuration
too. That's all.

Next, no matter how a service is started, Tails Server's CLI (or
similar) is involved somehow: if the user starts a service manually
through the GUI/CLI, then this is trivially true; if a service is marked
"autostart", when starting Tails we'll need a hook somewhere that calls
Tails Server's CLI in some way so that all such services are started.
So, Tails Server is involved in all cases, and can thus be responsible
for setting up these things.

Please let me know if I'm completely off here vs how you are thinking
about this!

>> # 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.
>
> Right. I didn't see this option either, but I think this would work too.
> I will try this :)

It's ~new, which might explain it. Any way, I really hope this approach
works out since it looks the cleanest of those presented so far!

Cheers!