Peter Palfrader wrote: > If we call it tor_hidden_service_sockets, then the onionshare usecase is > not really covered by that name. However, I'm also not sure that it's a > valid use-case - it probably ought to put the hidden service directory > into /var/lib/tor and use the control interface to learn the hostname. > Or use ephemeral hidden services via the control interface.
I can't speak for the onionshare developers, but the control interface
is not enabled by default, and can't be easily automatically enabled,
which makes it unappealing to depend on it if you can get things working
another way. There may be a permissions problem with them using
/var/lib/tor for the hidden service directory too.
Whether it makes sense to also cater to the onionshare needs with this
directory, or limit it to the hidden service socket use case,
I leave up to you.
> With the top directory not having any user specific modes, different tor
> instances can share that tree. I wonder if we still want
> /var/lib/tor-onion-sockets/{default,foo,bar} so that we get
> systemd protection and prevent a tor instance from accessing another
> instances's tree.
The permissions probably prevent such problems, at least if they are set
up as in my example with the socket file for a hidden service in a
directory that only the tor instance that serves it (and the user that
runs the service) can read.
But, it couldn't hurt to separate the directories and lock it down more.
--
see shy jo
signature.asc
Description: PGP signature
