[tor-bugs] #21818 [Core Tor/Tor]: tor's handling of SIGHUP considered harmful

[Tor Bug Tracker & Wiki]

#21818: tor's handling of SIGHUP considered harmful
------------------------------+------------------------------
     Reporter:  cypherpunks   |      Owner:
         Type:  defect        |     Status:  new
     Priority:  Medium        |  Milestone:
    Component:  Core Tor/Tor  |    Version:  Tor: unspecified
     Severity:  Normal        |   Keywords:
Actual Points:                |  Parent ID:
       Points:                |   Reviewer:
      Sponsor:                |
------------------------------+------------------------------
 When I run `systemctl reload tor` tor says `Received reload signal (hup).
 Reloading config and resetting internal state.` and then, under many
 perfectly valid configurations, terminates. (As an aside, I wonder what
 does "resetting internal state" mean. It isn't closing circuits; what
 state is being reset?)

 The "feature" of being able to reload the config at runtime is alluring,
 but it's a false promise because many configurations which are valid at
 startup are not valid after tor has already bound ports, dropped privs,
 and done whatever else it did at startup.

 The scenario which caused me to file this was that i attempted to add a
 listener on a privileged port. After getting a person in another country
 to reboot the machine for me (it's only reachable via hidden service) my
 new configuration was fine, but, attempting to "reload" tor's config was
 an extremely inconvenient mistake for me because, having already dropped
 privs, tor was not allowed to bind the port (`Permission denied`).

 See also #17873 for a similar but different scenario which led to the same
 problem.

 I'm not sure what solution I'd prefer for this problem, but here are a few
 possibilities:

 1. get rid of the runtime config reloading completely (easy, but lame)

 2. try to fail gently when reloading the config (report errors to the log,
 but don't die. probably a lot more work for an incomplete solution.)

 3. make SIGHUP cause tor to re-parse the config, report any errors it can,
 but not actually use the new config *unless* it contains a special new
 directive like `AllowRuntimeConfigChange 1` (the documentation for which
 would of course discuss the myriad ways this could make tor exit). (this
 might be the best option?)

 4. maybe #8195 gets rid of the privileged ports issue here, at least in
 some environs?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21818>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online