My first suggestion would be [...] My second suggestion would be to get a Tor binary and run it yourself, not as part of a package. If it works there, then you know that your next steps are to figure out why your package isn't working for you

Hi Yawning and Roger!

Thank you so much for trying to reproduce the bug and teaching me on the generic Tor debugging steps! I agree with you that:

If you can get a minimal case reproducing the bug without a package, systemd, etc, in the picture, that's a great time to file a trac ticket.

It turns out, to successfully reproduce this, we need:

0. set DisableNetwork to 1 1. use User option as part of the Tor configuration 2. run sudo Tor from a different user in a different group

Here are the specific steps to reproduce it. I tested it on Debian Stretch but it should be distribution independent:

user@host:~$ cat /home/user/my.torrc DataDirectory /tmp/tor ControlSocket /tmp/tor/control.sock ControlSocketsGroupWritable 1 CookieAuthentication 1 CookieAuthFileGroupReadable 1 CookieAuthFile /tmp/tor/control.authcookie SocksPort unix:/tmp/tor/socks.sock

user@host:~$ sudo /usr/bin/install -Z \ -m 02755 -o debian-tor \ -g debian-tor -d /tmp/tor

user@host:~$ ls -ld /tmp/tor/; ls -l /tmp/tor/ drwxr-s--- 2 debian-tor debian-tor 40 Feb 3 18:19 /tmp/tor/ total 0

user@host:~$ sudo /usr/bin/tor \ -f /home/user/my.torrc \ --User debian-tor \ --DisableNetwork 1

There should be control.sock, but not:

user@host:~$ ls -ld /tmp/tor/; sudo ls -l /tmp/tor/ drwx--S--- 2 debian-tor debian-tor 100 Feb 3 20:00 /tmp/tor/ total 8 -rw-r----- 1 debian-tor debian-tor 32 Feb 3 20:00 control.authcookie -rw------- 1 debian-tor debian-tor 0 Feb 3 20:00 lock -rw------- 1 debian-tor debian-tor 215 Feb 3 20:00 state

To let Tor really open the control.sock, we need to reload Tor (yes, even though we just start it):

user@host:~$ ps -A | grep tor 863 ? 00:00:00 xenstore-watch 927 ? 00:00:04 tor-controlport 11851 pts/0 00:00:00 tor

user@host:~$ sudo /bin/kill -HUP 11851

user@host:~$ ls -ld /tmp/tor/; sudo ls -l /tmp/tor/ drwx--S--- 2 debian-tor debian-tor 120 Feb 3 20:01 /tmp/tor/ total 8 -rw-r----- 1 debian-tor debian-tor 32 Feb 3 20:01 control.authcookie srw-rw---- 1 debian-tor debian-tor 0 Feb 3 20:01 control.sock -rw------- 1 debian-tor debian-tor 0 Feb 3 20:01 lock -rw------- 1 debian-tor debian-tor 215 Feb 3 20:01 state

I guess the reason Yawning was not able to reproduce it is because User option was not set:

user@host:~$ sudo -u debian-tor \ /usr/bin/tor -f /home/user/my.torrc \ --DisableNetwork 1

[notice] Opening Control listener on /tmp/tor/control.sock

I was thinking Tor fixing /tmp/tor/ to 2700 may be the reason, but then I cannot explain why this will work with /tmp/tor/ set to 2700:

user@host:~$ sudo /usr/bin/tor \ -f /home/user/my.torrc \ --User debian-tor \ --DisableNetwork 0

[notice] Opening Control listener on /tmp/tor/control.sock

Would you please share some insights on the this?

For temporary workaround using systemd in Debian, I put this line in the [Service] section of /lib/systemd/system/tor@default.service :

ExecStartPost=/bin/kill -HUP ${MAINPID}

Best Regards, iry