anonym: > 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.
Right. Do you have any other idea to solve this problem of making single files persistent? >> 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. > > [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. > # 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. > # 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 :) Cheers _______________________________________________ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.