[tor-dev] No Control Socket when DisableNetwork 1

[iry]

> 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 at 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 at host:~$ sudo /usr/bin/install -Z \
-m 02755 -o debian-tor \
-g debian-tor -d /tmp/tor

user at 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 at host:~$ sudo /usr/bin/tor \
-f /home/user/my.torrc \
--User debian-tor \
--DisableNetwork 1

There should be control.sock, but not:

user at 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 at 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 at host:~$ sudo /bin/kill -HUP 11851

user at 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 at 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 at 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 at default.service :

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

Best Regards,
iry



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20180203/8d0cbb10/attachment.sig>