[tor-onions] domain socket as HiddenServicePort target -- permissions!?

[David Goulet]

On 16 Jun (16:14:22), Johannes wrote:
> Hello Ivan,

Hi Johannes,

> 
> thanks for your reply. I am afraid you are describing a situation that
> you and I expect(ed) to be reality. But it is not.
> 
> Test 0:
> 
> INET socket, just to check basic connectivity of the .onion address.
> 
> => works
> 
> 
> Test 1:
> 
> Socket /tmp/hstest.socket with perms 0666. This is not a good idea, but
> could work.
> 
> => It does NOT work.
> 
> 
> Test 2:
> 
> Socket at /srv/hstest/test.socket; directory /srv/hstest has group of
> the Tor user, setgid set (02750), socket file  correctly inherits the
> group of the Tor user and has perms 0660. This is a setup that I think
> is reasonable.
> 
> * Confirmed via debug log, that the correct socket path is used.
> 
> * Checked with a local unix domain http client, ran as the Tor daemon's
> user => works.
> 
> * Checked via onion: => does NOT work.

Can you send the HiddenServicePort line that you use (you can obfuscate path
and port) for the Unix socket.

Then the "ls -al" of the Unix socket once created. Does the user or group of
the Tor user has at least "w" access?

Also, what do you mean by "Checked via onion" does NOT work? You tried to
access the .onion and it doesn't reach the Unix socket? If so, one easy way
would be to nc -u /tmp/some.sock -l and bind the HS to that socket. See if you
get the data. If you get it, then the Unix socket application support is the
issue, else we have another issue.

I use extensively Unix socket for HS so I can tell you it works but the
permissions are can be tricky.

Thanks!
David

> 
> 
> Test x:
> 
> Some unknown ad hoc created set of directory layout, ownerships and
> permissions--using root privileges that will totally not be available to
> the daemon's user and in its chroot. Not reproducible, because of the
> magnitude of possible combinations, the inability to debug this via
> Tor's logging, lack of documentation and my current level of frustration
> ...
> 
> => Worked. Somehow. Forgot how, because I didn't know what to look for.
> 
> /rant
> 
> 
> Obviously there are some checks done by Tor on the socket, the
> containing directory or both. My question is: What *exactly* is checked
> and what is the rationale in this case in contrast to the rationale
> applied to the checks done for domain sockets at other functionality
> than HS?
> 
> Cheers,
> Johannes
> 
> On 06/15/2016 09:32 PM, Ivan Markin wrote:
> 
> > A unix socket should be readable and writeable for the user under which
> > you're running tor ("tor", "_tor" etc). As well as for the server (nginx
> > or whatever). So you need some combination that provides 'rw-' access
> > for all relevant users ("nginx"/"www", "tor"/"_tor"...). E.g. this can
> > be accomplished by adding these users to some "onionservice" group or
> > whichever you like.
> > 
> > P.S. You can test connectivity with `curl` by running something like this:
> > $ curl --unix-socket /path/to/socket http:///
> > 
> > --
> > Sweet onions,
> > Ivan Markin
> > _______________________________________________
> > tor-onions mailing list
> > tor-onions at lists.torproject.org
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions
> > 
> _______________________________________________
> tor-onions mailing list
> tor-onions at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-onions/attachments/20160616/339c179c/attachment.sig>