-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Dear Tor Developers,
According to the Tor manual: https://www.torproject.org/docs/tor-manual-dev.html.en
DisableNetwork 0|1 When this option is set, we don’t listen for or accept any connections other than controller connections, and we close (and don’t reattempt) any outbound connections. Controllers sometimes use this option to avoid using the network until Tor is fully configured. (Default: 0)
However, it seems when DisableNetwork is set to 1, /var/run/tor/control does not exist anymore making us cannot get a controller from socket file. (stem.control.Controller.from_socket_file() is affected in this case: https://stem.torproject.org/api/control.html#stem.control.Controller.fro m_socket_file)
To reproduce this, I tested both Tor 0.3.1.9 and 0.3.2.9 on Debian Stretch:
When DisableNetwork 0, run: systemctl --no-pager restart tor@default
user@host:~$ ls -l /var/run/tor/ total 1328 srw-rw---- 1 debian-tor debian-tor 0 Jan 19 21:14 control -rw-r----- 1 debian-tor debian-tor 32 Jan 19 21:14 control.authcookie -rw-r----- 1 debian-tor debian-tor 1350116 Jan 19 21:14 log srw-rw-rw- 1 debian-tor debian-tor 0 Jan 19 21:14 socks -rw-r--r-- 1 debian-tor debian-tor 6 Jan 19 21:14 tor.pid
When DisableNetwork 1, run: systemctl --no-pager restart tor@default
user@host:~$ ls -l /var/run/tor/ total 1244 -rw-r----- 1 debian-tor debian-tor 32 Jan 19 21:00 control.authcookie -rw-r----- 1 debian-tor debian-tor 1269005 Jan 19 21:00 log
I searched on Tor-trac but did not find any similar report. Therefore, would you please tell me wether Tor intentionally behaves like this or this is a bug? (If this is a bug, I can definitely help to report it to Tor-trac.)
Thank you so much!
Best Regards, iry
On Fri, 19 Jan 2018 23:22:00 +0000 iry iry@riseup.net wrote:
According to the Tor manual: https://www.torproject.org/docs/tor-manual-dev.html.en
DisableNetwork 0|1 When this option is set, we don’t listen for or accept any connections other than controller connections, and we close (and don’t reattempt) any outbound connections. Controllers sometimes use this option to avoid using the network until Tor is fully configured. (Default: 0)
However, it seems when DisableNetwork is set to 1, /var/run/tor/control does not exist anymore making us cannot get a controller from socket file. (stem.control.Controller.from_socket_file() is affected in this case: https://stem.torproject.org/api/control.html#stem.control.Controller.fro m_socket_file)
I'm fairly certain you are doing something wrong, because I'm using a tor process that was launched with DisableNetwork set to 1 in the torrc, and toggled to 0 via the ControlPort right now to browse the web (Tested with the copy of 0.3.1.9 that is distributed with Tor Browser).
https://gitweb.torproject.org/tor-browser/sandboxed-tor-browser.git/tree/dat... https://gitweb.torproject.org/tor-browser/sandboxed-tor-browser.git/tree/src...
To reproduce this working, if anyone out there still uses the sandbox I wrote, and can get a working browser without using an external tor instance, ta dah, it's working.
Normal Tor Browser has a similar launch process, and can even be coaxed into using AF_UNIX sockets (though it's utterly pointless to do so).
nb: It can take a while for the control port to actually be available after the tor daemon is spawned. The best way I found to deal with this is via using `ControlPortWriteToFile` since the file gets created after the control port listener is created. You could also use something like inotify on Linux, but that's non-portable.
Regards,
On Fri, Jan 19, 2018 at 11:22:00PM +0000, iry wrote:
However, it seems when DisableNetwork is set to 1, /var/run/tor/control does not exist anymore making us cannot get a controller from socket file. [...] I searched on Tor-trac but did not find any similar report. Therefore, would you please tell me wether Tor intentionally behaves like this or this is a bug? (If this is a bug, I can definitely help to report it to Tor-trac.)
Yeah, I think this is supposed to work. In fact, I agree with Yawning in that I think it *does* work.
My first suggestion would be to see if your Tor process actually successfully started in the "DisableNetwork 1" case. Maybe it didn't actually start up? Maybe the logs give you some hints?
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.
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.
Thanks! --Roger
On Sat, 20 Jan 2018 04:40:53 -0500 Roger Dingledine arma@mit.edu wrote:
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.
With a torrc that looks like this:
DataDirectory /tmp/tor ControlPort unix:/tmp/tor/control.sock SocksPort unix:/tmp/tor/socks.sock DisableNetwork 1
Running 0.3.1.9 I got from my distribution's package manager:
Jan 2013:31:28.986 [notice] Opening Control listener on /tmp/tor/control.sock
And a trivial test that exercises the control port works:
amiens :: ~ % nc -U /tmp/tor/control.sock PROTOCOLINFO 250-PROTOCOLINFO 1 250-AUTH METHODS=NULL 250-VERSION Tor="0.3.1.9" 250 OK
So digging into this further probably requires the "next steps". I still recommend a bit of a wait for tor to open the AF_UNIX socket. While it usually is nearly instantaneous on modern systems, I had intermittent problems with "the socket isn't there" related to trying too fast.
Regards,
-
iry -
Roger Dingledine -
Yawning Angel