Opened 3 years ago

Closed 3 years ago

#16703 closed defect (fixed)

If we touch the Ed25519 master ID key, Tor ignores the torrc file after reload signal (HUP)

Reported by: s7r Owned by: nickm
Priority: Medium Milestone: Tor: 0.2.7.x-final
Component: Core Tor/Tor Version: Tor: 0.2.7.2-alpha
Severity: Keywords: Ed25519 TorCoreTeam201509 PostFreeze027
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Tor 0.2.7.2-alpha on Debian Jessie.

Tor generated an Ed25519 master ID key in /datadirectory/keys and started relay functionality fine. We were in the consensus, all going normal. The RSA identity was previously there - this was an upgrade from Tor 0.2.5.12. Signing key and key-cert were also generated for 30 days (default), since I didn't configure a SigningKeyLifetime argument in torrc.

After the first reload signal (HUP), probably for log rotation, Tor ignored the existent and otherwise working config file in /etc/tor/torrc:

Jul 31 08:48:26.000 [notice] Received reload signal (hup). Reloading config and resetting internal state.
Jul 31 08:48:26.000 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Jul 31 08:48:26.000 [warn] Couldn't find $HOME environment variable while expanding "~/.torrc"; defaulting to "".
Jul 31 08:48:26.000 [notice] Configuration file "/etc/tor/torrc" not present, using reasonable defaults.

I moved the Ed25519 master ID key back to /datadirectory/keys. Did a service tor restart/start (not reload). It worked with the config file in /etc/tor/torrc and started just fine:

Jul 31 08:53:01.000 [notice] Bootstrapped 100%: Done
Jul 31 08:53:01.000 [notice] Now checking whether ORPort <ipv4>:port is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Jul 31 08:53:02.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Jul 31 08:53:53.000 [notice] Performing bandwidth self-test...done.

To test, I tried again service tor reload. Again it ignored my config file in /etc/tor/torrc and disabled relay functionality:

Jul 31 10:55:59.000 [notice] Received reload signal (hup). Reloading config and resetting internal state.
Jul 31 10:55:59.000 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Jul 31 10:55:59.000 [notice] Configuration file "/etc/tor/torrc" not present, using reasonable defaults.
Jul 31 10:55:59.000 [notice] Opening Socks listener on 127.0.0.1:9050
Jul 31 10:55:59.000 [notice] Closing no-longer-configured Control listener on 127.0.0.1:9051
Jul 31 10:55:59.000 [notice] Closing no-longer-configured OR listener on <ipv6>:port
Jul 31 10:55:59.000 [notice] Closing no-longer-configured OR listener on <ipv4>:port
Jul 31 10:55:59.000 [notice] Tor 0.2.7.2-alpha-dev (git-cedc651deb9e9db6+2b91e7f) opening log file.
Jul 31 10:55:59.000 [notice] Closing old Control listener on 127.0.0.1:9051
Jul 31 10:55:59.000 [notice] Closing old OR listener on <ipv6>:port
Jul 31 10:55:59.000 [notice] Closing old OR listener on <ipv4>:port

Here are the permissions on the Ed25519 master ID key:

  File: `ed25519_master_id_secret_key'
  Size: 96              Blocks: 8          IO Block: 4096   regular file
Device: 47a0b641h/1201714753d   Inode: 394256      Links: 1
Access: (0600/-rw-------)  Uid: (  102/debian-tor)   Gid: (  104/debian-tor)
Access: 2015-07-31 08:49:46.734656706 -0400
Modify: 2015-07-01 13:32:27.213920044 -0400
Change: 2015-07-29 04:02:46.913674620 -0400
 Birth: -

I want to highlight that I have other relays running 0.2.7.2-alpha (the same upgraded from 0.2.5.12) where I haven't touched the Ed25519 master ID key and they work very well unattended, nothing weird happens after a reload signal (HUP).

Child Tickets

Change History (5)

comment:1 Changed 3 years ago by nickm

Parent ID: #16685#16790

comment:2 Changed 3 years ago by nickm

Keywords: TorCoreTeam201509 PostFreeze027 added
Owner: set to nickm
Status: newassigned

comment:3 Changed 3 years ago by nickm

Parent ID: #16790

comment:4 Changed 3 years ago by nickm

I tried this and can't reproduce it. Can you write me some really simple instructions, if this is still happening?

comment:5 Changed 3 years ago by s7r

Resolution: fixed
Status: assignedclosed

In latest master it doesn't happen any more, couldn't reproduce it. I will close this ticket for now and reopen it in case we see this again.

Note: See TracTickets for help on using tickets.