Opened 18 months ago

Last modified 8 days ago

#21818 new defect

tor's handling of SIGHUP considered harmful

Reported by: cypherpunks Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: 035-roadmap-proposed
Cc: dmr, traumschule Actual Points:
Parent ID: #25510 Points:
Reviewer: Sponsor:

Description

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)
  1. 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.)
  1. 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?)
  1. maybe #8195 gets rid of the privileged ports issue here, at least in some environs?

Child Tickets

TicketStatusOwnerSummaryComponent
#27192closedPerform --verify-config before reloading torCore Tor/Tor

Change History (6)

comment:1 in reply to:  description Changed 15 months ago by teor

Parent ID: #17873

Replying to cypherpunks:

...

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

Try __ReloadTorrcOnSIGHUP 0 to make this happen.

Otherwise, this appears to be an instance of #17873.

comment:2 Changed 15 months ago by dgoulet

Milestone: Tor: unspecified

Missing milestone.

comment:3 Changed 5 months ago by teor

Parent ID: #17873#25510
Version: Tor: unspecified

This ticket is relevant to mobile embedding, and is more likely to get fixed there.

comment:4 Changed 3 months ago by nickm

Keywords: 035-roadmap-proposed added

comment:5 Changed 5 weeks ago by dmr

Cc: dmr added

comment:6 Changed 8 days ago by traumschule

Cc: traumschule added
Note: See TracTickets for help on using tickets.