Opened 4 years ago

Last modified 3 years ago

#21974 new defect

Race: Tor declares controlport listener open before it has written its controlcookie to disk

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-control startup refactor race-condition
Cc: catalyst Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by arma)

When I start my Tor client, I see this in its logs:

Apr 17 00:49:35.238 [notice] Opening Control listener on

In fact, controllers like txtorcon and nyx might imagine that they can use this log line as an indication that the control port is up and usable:

But looking through Tor's code, that log line comes from connection_listener_new() which comes from retry_listener_ports() which comes from retry_all_listeners() which comes from options_act_reversible(), which gets called before options_act(), which is where we call init_control_cookie_authentication().


A) Is there a recommendation we can make to controllers about how they can know when our control port is ready? I guess the answer right now is "when the control port is open and also when the control cookie file is there"? Is that accurate? Should we worry about races writing/reading the cookie file?

B) Should we rearrange the order of stuff in options_act*() so things are in place for the control port when we do the log message indicating that it's open?

C) We sure have a bunch of stuff we do at startup now, and the dependency graph of what has to happen before what is complicated, and I bet there are bugs in the current order of things. I've opened #21975 for this bigger refactor idea.

Child Tickets

Change History (7)

comment:1 Changed 4 years ago by atagar

For what it's worth as mentioned on irc this isn't an issue for Stem (or by extension Nyx). We use the bootstrap messages and in practice tor's available once it reports 5%.

comment:2 Changed 4 years ago by arma

Description: modified (diff)

comment:3 Changed 4 years ago by yawning

While this issue is being addressed, control_ports_write_to_file() is also called before the auth cookie is written out.

comment:4 Changed 4 years ago by dgoulet

Milestone: Tor: unspecified

comment:5 Changed 4 years ago by catalyst

Cc: catalyst added

comment:6 Changed 3 years ago by teor

There is a race condition here, but it requires a specific set of circumstances.

Most clients:

  1. Connect to the control port
  3. Read the cookie file name you are given

It's impossible for Tor to reply before it has written the cookie file, because Tor has a single event-driven thread, which imposes the following order:

  1. Tor starts up and reads its config
  2. Tor opens the control port
  3. Tor writes the cookie file
  4. Tor responds to requests on the control port

There are two rare cases where there is a race condition:

  1. The controller assumes that the cookie file is located at a particular location (it could cache it, hard-code it, or ask the user for it), and reads it before issuing a PROTOCOLINFO.
  2. Tor is being reconfigured, and responds to requests based on the old config

Case A is technically a protocol violation, but we should support it.
I don't think it's possible for us to fix Case B.

comment:7 Changed 3 years ago by nickm

Keywords: tor-control startup refactor race-condition added
Note: See TracTickets for help on using tickets.