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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions
tor-onions mailing list tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions