Relay crash when reloading and resolv.conf is empty
Mar 21 00:11:06 hostnaem Tor[1907]: Unable to parse '/etc/resolv.conf', or no nameservers in '/etc/resolv.conf' (6)
Mar 21 00:11:06 hostnaem Tor[1907]: set_options(): Bug: Acting on config options left us in a broken state. Dying.This just happened on my 0.2.7.0-alpha-dev build. resolv.conf contains only a "search" parameter, but no nameservers.
Activity
changed milestone to %Tor: 0.4.0.x-final
added 034-included-20180405 034-triage-20180328 035-removed-20180711 component::core tor/tor crash dns dos-maybe milestone::Tor: 0.4.0.x-final owner::nickm parent::21900 points::small priority::high resolution::fixed resolv.conf security severity::normal status::closed tor-relay type::defect version::tor 0.2.7.1-alpha labels
Unfortunately this also affects non-exits which probably should not bother to try to configure nameservers in the first place.
Maybe dns_init() and dns_reset() should check options->ExitRelay instead of server_mode(options)?
BTW, this has been previously reported with a less precise title as #9990 (moved).
Trac:
Severity: N/A to Normal#15421 (moved) workaround for non-exits
See also #21900 (moved)
Trac:
Keywords: N/A deleted, tor-relay resolv.conf dns added
Cc: N/A to teor
Reviewer: N/A to N/AI'll collect all the cases under #21900 (moved) so we fix them all at once. (Or at least we document which are fixed and which are not.)
Trac:
Parent: N/A to #21900 (moved)Hi there, yesterday I ran into an issue that looks like this too. Here's the repro steps I provided from #23036 (moved) with the latest git tip (tor commit bb66a48).
Repro steps:
-
Start system without a network connection.
-
Start tor, torrc I used was...
% cat ~/.tor/torrc ControlPort 9051 ExitPolicy reject *:*- Set the ORPort with "SETCONF ORPort=9090".
Result:
Tor process terminates with...
Jul 25 19:21:33.000 [warn] ControlPort is open, but no authentication method has been configured. This means that any program on your computer can reconfigure your Tor. That's bad! You should upgrade your Tor controller as soon as possible. Jul 25 19:21:33.000 [notice] Opening OR listener on 0.0.0.0:9090 Jul 25 19:21:33.000 [notice] You are running a new relay. Thanks for helping the Tor network! If you wish to know what will happen in the upcoming weeks regarding its usage, have a look at https://blog.torproject.org/blog/lifecycle-of-a-new-relay Jul 25 19:21:33.000 [notice] It looks like I need to generate and sign a new medium-term signing key, because I don't have one. To do that, I need to load (or create) the permanent master identity key. If the master identity key was not moved or encrypted with a passphrase, this will be done automatically and no further action is required. Otherwise, provide the necessary data using 'tor --keygen' to do it manually. Jul 25 19:21:33.000 [notice] Your Tor server's identity key fingerprint is 'Unnamed 4853AB6F9215A837EA3562CF4AF00713737FDF01' Jul 25 19:21:33.000 [warn] Unable to parse '/etc/resolv.conf', or no nameservers in '/etc/resolv.conf' (6) Jul 25 19:21:33.000 [err] set_options(): Bug: Acting on config options left us in a broken state. Dying. (on Tor 0.3.2.0-alpha-dev bb66a48541aa5110)Cheers! -Damian
-
This could be a potential DoS risk if DNS goes down for an exit, and it is HUP'ed while DNS its down. It would be nice to get it fixed in the next year or so.
Damian, can you confirm that your system is non-macOS?
Trac:
Keywords: tor-relay resolv.conf dns deleted, tor-relay resolv.conf dns dos-maybe added
Milestone: Tor: unspecified to Tor: 0.3.3.x-final-
So current the logic in dns.c:configure_nameservers() is (simplified):
clear_nameservers(); if (parse_resolv_conf()) { warn(); goto err; }You can see why this is hard to fix: by the time that we notice that we can't parse resolv.conf, we have already cleared all the old nameservers.
Ideally, what we'd like to have is an safe way to load resolv.conf and replace the current nameservers on success, or do nothing on failure. Libevent's evdns code does not provide this, afaik.
From what I can tell, there are three options here:
- Patch libevent to provide an option to do what we want.
- When reloading resolv.conf, create a new evdns_base, and only replace the old evdns_base with it if the load is successful. The problem here is that our existing logic assumes that the evdns_base stays the same object forever. I worry that changing this assumption could lead to tricky bugs.
- When reloading resolv.conf, first try to create a new dummy evdns_base with the new resolv.conf. Free it immediately. Only if that load succeeds should we try to do the clear-and-replace logic above.
I think option 3 is our best shot for now, even though it has a race condition.
Additionally, we can improve the situation by making this error non-fatal on non-exits, assuming it can still happen there.
Trac:
Status: new to accepted
Owner: N/A to nickm mentioned in issue #21900 (moved)
mentioned in issue #23036 (moved)
moved to tpo/core/tor#15421 (closed)
