Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#18548 closed defect (fixed)

Tor calling sandbox_getaddrinfo() delays bootstrap when no system DNS is available

Reported by: anonym Owned by:
Priority: Medium Milestone: Tor: 0.2.8.x-final
Component: Core Tor/Tor Version: Tor: 0.2.7.6
Severity: Normal Keywords: AffectsTails 027-backport
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

On a Debian Jessie system with tor installed from jessie-backports (currently 0.2.7.6-1~bpo8+1), if I:

  • enable Tor's sandboxing, and
  • empty /etc/resolv.conf, and
  • restart Tor to make it bootstrap again,

then I can see Tor doing nothing for exactly 10 seconds even before reporting Bootstrapped 0%. In the debug log I see:

Mar 14 19:30:20.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Mar 14 19:30:20.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Mar 14 19:30:20.000 [info] crypto_global_init(): NOT using OpenSSL engine support.
Mar 14 19:30:20.000 [info] evaluate_evp_for_aes(): This version of OpenSSL has a known-good EVP counter-mode implementation. Using it.
Mar 14 19:30:20.000 [info] sandbox_getaddrinfo(): (Sandbox) getaddrinfo succeeded.
Mar 14 19:30:30.000 [info] sandbox_getaddrinfo(): (Sandbox) getaddrinfo failed.
Mar 14 19:30:30.000 [info] sandbox_getaddrinfo(): (Sandbox) getaddrinfo succeeded.
Mar 14 19:30:30.000 [notice] Bootstrapped 0%: Starting

As you can see there is an exact 10 second delay for the second call of sandbox_getaddrinfo(). Either using a "normal" system DNS resolver, or disabling Tor's sandboxing removes this delay. I say "normal" system DNS resolver, because using Tor's DNSPort doesn't work, as expected, but actually it makes the situation worse by increasing the delay to 20 seconds for some reason. I imagine this is quite a common use case for the DNSPort option.

For the record, this Tor bootstrap delay affects every boot of Tails (probably since we enabled Tor's sandboxing in Tails 1.2, 1½ years ago) and we have our own ticket but it tracks other unrelated Tor bootstrapping issues as well.

Child Tickets

Change History (8)

comment:1 Changed 4 years ago by nickm

It looks like the main culprit here is the init_addrinfo() call, which tries to resolve our own hostname and cache the result. I wonder why it was necessary to do that. Does anything break if you remove the body of init_addrinfo()?

DNSPort doesn't have anything to do with the Tor client's use of getaddrinfo as far as I know. Not sure why you're seeing that.

comment:2 Changed 4 years ago by nickm

Milestone: Tor: 0.2.8.x-final

comment:3 in reply to:  1 Changed 4 years ago by anonym

Replying to nickm:

It looks like the main culprit here is the init_addrinfo() call, which tries to resolve our own hostname and cache the result. I wonder why it was necessary to do that. Does anything break if you remove the body of init_addrinfo()?

Doing so fixes the delay issue, as expected. I cannot see any obvious regressions: basic client usage still works; nothing new happened on the info+ level in log (I didn't check the debug level cause I don't have the expected patterns memorized :)). Not sure about non-client operation, though.

DNSPort doesn't have anything to do with the Tor client's use of getaddrinfo as far as I know. Not sure why you're seeing that.

Sure. What I wanted to highlight is that configuring Tor's DNSPort as the system resolver, which I *assume* is pretty common and one reason for introducing that feature in the first place, triggers the problem. Just ignore the part about the delay doubling; while somewhat interesting, it's a bit beside the point.

comment:4 Changed 4 years ago by nickm

Keywords: 027-backport added
Status: newneeds_review

Not sure about non-client operation, though.

Hm. From what I can tell, based on grepping users of gethostname(), this is used only in resolve_my_address() in config.c, and that function is only called for non-clients.

We already disallow changes to server_mode() while sandboxing is active, so we could probably get away with something like the patch I just kludged together in branch bug18548.

comment:5 Changed 4 years ago by nickm

(please review?)

comment:6 Changed 3 years ago by Sebastian

review on #18253

comment:7 Changed 3 years ago by nickm

Resolution: fixed
Status: needs_reviewclosed

Merged; thanks!

comment:8 Changed 3 years ago by nickm

(Not backporting to 0.2.7, but feel free to cherry-pick the commit to your branches as needed.)

Note: See TracTickets for help on using tickets.