Opened 17 months ago

Last modified 15 months ago

#25173 new defect

No Control Socket when DisableNetwork and User options are set

Reported by: iry Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.3.1.9
Severity: Normal Keywords: 033-triage-20180320, 033-removed-20180320
Cc: whonix-devel@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

To successfully reproduce this, we need:

  1. set DisableNetwork to 1
  2. use User option as part of the Tor configuration
  3. 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

Child Tickets

Change History (13)

comment:1 Changed 17 months ago by iry

For temporary workaround using systemd in Debian, I put these lines in the
/lib/systemd/system/tor@…/controlport-workaround.service :

[Service]
ExecStartPost=/bin/kill -HUP ${MAINPID}

comment:2 Changed 17 months ago by iry

I am too afraid to say it is a Tor bug because I may be the one who did something wrong. Therefore, could anyone please help me to check this?

comment:3 Changed 17 months ago by teor

Milestone: Tor: 0.3.3.x-final
Status: newneeds_information

You don't say what tor version you are running. That makes it hard for us to work out where the bug is.

comment:4 Changed 17 months ago by iry

Version: Tor: unspecifiedTor: 0.3.2.9

Thank you, teor!

I tested both Tor 0.3.1.9 and 0.3.2.9 on Debian Stretch

comment:5 Changed 17 months ago by yawning

Log output if any is helpful as well (and there is a debug log level).

comment:6 Changed 17 months ago by teor

Version: Tor: 0.3.2.9Tor: 0.3.1.9

We use the earliest version that a bug appears in. That makes it easier to find the bug.

Looking forward to seeing logs of what Tor does with the control socket file on startup and on HUP. That will give us some clues.

comment:7 Changed 17 months ago by arma

Our first weird hint. Not using the User option, we have

Feb 07 22:06:02.093 [notice] Read configuration file "/usr/local/etc/tor/torrc".
Feb 07 22:06:02.098 [warn] ControlPort is open, but no authentication method has been configured.  This means that any program on your computer can reconfigure your Tor.  That's bad!  You should upgrade your Tor controller as soon as possible.
Feb 07 22:06:02.098 [notice] Scheduler type KIST has been enabled.
Feb 07 22:06:02.098 [notice] Opening Socks listener on 127.0.0.1:9050
Feb 07 22:06:02.098 [notice] Opening Control listener on 127.0.0.1:9051
Feb 07 22:06:02.098 [notice] Opening Control listener on /home/arma/.tor/control
Feb 07 22:06:02.098 [notice] Opening Control listener on /tmp/tor/control.sock
Feb 07 22:06:02.098 [warn] Your log may contain sensitive information - you disabled SafeLogging, and you're logging more than "notice". Don't log unless it serves an important reason. Overwrite the log afterwards.
Feb 07 22:06:02.103 [notice] Parsing GEOIP IPv4 file /usr/local/share/tor/geoip.
Feb 07 22:06:02.220 [notice] Parsing GEOIP IPv6 file /usr/local/share/tor/geoip6.
Feb 07 22:06:02.726 [notice] Bootstrapped 0%: Starting

That is, our controlsocket opens at the same time as the control port.

But using User, we have

Feb 07 21:25:12.170 [notice] Read configuration file "/tmp/torrc".
Feb 07 21:25:12.175 [notice] Scheduler type KIST has been enabled.
Feb 07 21:25:12.175 [notice] Opening Socks listener on 127.0.0.1:9050
Feb 07 21:25:12.000 [notice] Parsing GEOIP IPv4 file /usr/local/share/tor/geoip.
Feb 07 21:25:12.000 [notice] Parsing GEOIP IPv6 file /usr/local/share/tor/geoip6.
Feb 07 21:25:12.000 [notice] Bootstrapped 0%: Starting
Feb 07 21:25:12.000 [notice] Starting with guard context "default"
Feb 07 21:25:12.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Feb 07 21:25:13.000 [notice] Opening Control listener on /tmp/tor/control.sock
Feb 07 21:25:13.000 [notice] Bootstrapped 85%: Finishing handshake with first hop

What in our code path is making us open the control socket listener so much later when User is set?

comment:8 Changed 17 months ago by arma

#ifndef _WIN32
    /* We don't need to be root to create a UNIX socket, so defer until after
     * setuid. */
    const or_options_t *options = get_options();
    if (port->is_unix_addr && !geteuid() && (options->User) &&
        strcmp(options->User, "root"))
      continue;
#endif /* !defined(_WIN32) */

is where we defer opening the control socket listener

comment:9 Changed 17 months ago by arma

My guess is that we defer opening the unix domain socket here, and then we never call retry_all_listeners() again from config.c because our config hasn't changed.

There's a call to retry_all_listeners() in main.c, in this thing called retry_listeners_callback(), except it runs

  if (!net_is_disabled()) {
    retry_all_listeners(NULL, NULL, 0);

so when net_is_disabled, it just never calls retry_all_listeners again.

comment:10 Changed 15 months ago by nickm

Keywords: 033-triage-20180320 added

Marking all tickets reached by current round of 033 triage.

comment:11 Changed 15 months ago by nickm

Keywords: 033-removed-20180320 added

Mark all not-already-included tickets as pending review for removal from 0.3.3 milestone.

comment:12 Changed 15 months ago by arma

Status: needs_informationnew

Setting back out of needs-information, since we know what the bug is (see my comments 7-9): the bug is that we're doing the wrong thing for opening our control sockets.

comment:13 Changed 15 months ago by nickm

Milestone: Tor: 0.3.3.x-finalTor: unspecified
Note: See TracTickets for help on using tickets.