anonym:
> 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. :)
Wow, that would be great. We talked about this feature before and we
agreed that it would be great if we had this, but I don't think you
offered to do this yourself :) Actually, I took a look at the
persistence backend to figure out what would be needed to get this done,
but I was deterred by the vast amount of perl code :D
> 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?
ACK. I agree that the other options are better than making the torrc
persistent. But I still need to make single configuration files
persistent (e.g. /etc/mumble-server.ini).
> [...]
>>> # 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.
That would work, but I prefer the other options :)
>
>>> # 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.).
Just to clarify things: Currently Tails Server does have a configuration
file for each service (which is made persistent if the service is
persistent). Those are currently in /usr/share/tails-server/options/,
e.g. /usr/share/tails-server/options/mumble. But I only store options in
there which are not part of some other configuration file, in order to
prevent redundancy and inconsistent states. So everytime Tails Server
needs the value of an user option, the corresponding configuration file
(e.g. /etc/mumble-server.ini for the server password) is parsed.
(But the persistent option is not stored anywhere else, so it is stored
in this internal options file.)
Please tell me if you see any problems with this approach.
> Probably we'd also store all "persistent" hs keys here too.
You mean the private key from the hidden service directory? I simply
make the hidden service directory (e.g. /var/lib/tor/mumble) persistent,
so I don't store this key anywhere else. I could move the hidden service
directory
Beyond this, each service marked
> "persistent" would have some directory for its persistent configuration
> too. That's all.
ACK.
>
> 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.
Right, that's exactly how I started impementing it right now :)
> 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!
I'm positive that this will work. But I think I will use the old
create_hidden_service() [1] instead of the new
create_ephemeral_hidden_service() [2], because the latter does not
create a hidden service directory, which I need to make the service
persistent. Also, only create_hidden_service() supports client
authentication, which I want to support.
[1]
https://stem.torproject.org/api/control.html#stem.control.Controller.create_hidden_service
[2]
https://stem.torproject.org/api/control.html#stem.control.Controller.create_ephemeral_hidden_service
Cheers
