Opened 5 years ago

Closed 2 years ago

#12478 closed defect (wontfix)

Ownership error on hidden service dir encountered on config reload kills Tor process

Reported by: andrea Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.2.4.20
Severity: Normal Keywords: tor-hs
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

If you add a new hidden service to your torrc with a hidden service dir not owned by the Tor process user (I ran across this by rsyncing an HS dir from another box), and SIGHUP the Tor process, the error adding the HS is not handled cleanly:

Example:

Jun 26 20:14:06.000 [notice] Received reload signal (hup). Reloading config and resetting internal state.
Jun 26 20:14:06.000 [notice] Read configuration file "/etc/tor/torrc".
Jun 26 20:14:06.000 [notice] Tor 0.2.4.20 opening log file.
Jun 26 20:14:06.000 [warn] /var/tor/bitcoind_hidden_service/ is not owned by this user (tor, 58) but by root (0). Perhaps you are running Tor as the wrong user?
Jun 26 20:14:06.000 [warn] Error loading rendezvous service keys
Jun 26 20:14:06.000 [err] set_options(): Bug: Acting on config options left us in a broken state. Dying.

Child Tickets

Change History (7)

comment:1 Changed 5 years ago by nickm

Milestone: Tor: 0.2.6.x-finalTor: 0.2.???

comment:2 Changed 3 years ago by arma

Severity: Normal

What's the suggested better behavior? Silently accepting the hup but not acting on the config options will produce confusion in the other direction. (Writing "I didn't act on your config. Surprise!" in the logs is great for people who read logs, but it won't reach people who just HUP their Tor and move on.)

comment:3 Changed 3 years ago by dgoulet

Keywords: tor-hs added

Both are not ideal but I think having tor process dying makes it the only obvious way the user can notice that something is wrong... else the HUP does nothing, user thinks all is good and very bad failure of UX.

How about we don't allow the HUP to load newly configured hidden service?... seems harsh but this would force the user to restart tor and thus notice the error instead of tor dying all of the sudden?

Alternative is to not fail and expect the user to check the logs to see why her HS is not accessible :).

comment:4 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:5 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:6 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:7 Changed 2 years ago by nickm

Resolution: wontfix
Status: newclosed

This is a general case of the property where if you HUP into a bad configuration, Tor will stop.

Note: See TracTickets for help on using tickets.