[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #15421 [Core Tor/Tor]: Relay crash when reloading and resolv.conf is empty

#15421: Relay crash when reloading and resolv.conf is empty
-------------------------------------------------+-------------------------
 Reporter:  TvdW                                 |          Owner:  nickm
     Type:  defect                               |         Status:
                                                 |  accepted
 Priority:  High                                 |      Milestone:  Tor:
                                                 |  0.3.3.x-final
Component:  Core Tor/Tor                         |        Version:  Tor:
                                                 |  0.2.7.1-alpha
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-relay resolv.conf  dns dos-      |  Actual Points:
  maybe 033-must crash                           |
Parent ID:  #21900                               |         Points:  small
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------
Changes (by nickm):

 * status:  new => accepted
 * owner:  (none) => nickm


Comment:

 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:

 1. Patch libevent to provide an option to do what we want.
 2. 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.
 3. 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.

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

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs