[tor-dev] No Control Socket when DisableNetwork 1

[iry]

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

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
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

[Yawning Angel]

On Fri, 19 Jan 2018 23:22:00 +0000

Post by iry
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.
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/data/torrc
https://gitweb.torproject.org/tor-browser/sandboxed-tor-browser.git/tree/src/cmd/sandboxed-tor-browser/internal/tor/tor.go#n342

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,

[Roger Dingledine]

Post by iry
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

[Yawning Angel]

On Sat, 20 Jan 2018 04:40:53 -0500

Post by Roger Dingledine
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,