#27306 closed defect (fixed)

'GETINFO exit-policy/full' fails when disconnected

Reported by: atagar Owned by:
Priority: High Milestone:
Component: Core Tor/Stem Version:
Severity: Major Keywords:
Cc: rl1987 Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Hi lovely network team folks. When not connected to a network the GETINFO exit-policy/full command fails with 551 Descriptor still rebuilding - not ready yet.

This is with tor commit 7e4ac02.

% cat ~/.tor/torrc
DataDirectory /home/atagar/.tor
ORPort 9052
ControlPort 9051
ExitPolicy reject *:*
% telnet localhost 9051
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
AUTHENTICATE
250 OK
GETINFO exit-policy/full
551 Descriptor still rebuilding - not ready yet

This concerns me because stem's get_exit_policy() method now relies on this GETINFO option. Previously I failed back to our own (somewhat complicated) python code for puzzling out our exit policy. I dropped that recently since this
GETINFO option is now universally available on all non-deprecated tor versions.

Definitely rather not re-add our python fallback to work around this. :P

Child Tickets

Change History (9)

comment:1 Changed 11 months ago by teor

Keywords: regression 035-must 034-must added
Milestone: Tor: 0.3.5.x-final
Status: newneeds_information

I couldn't find anything that seemed related in that particular commit, or the week of commits before it,

When did it work last?
Which master commit?
Does it work on the maint branches 0.3.4, 0.3.3, 0.3.2, or 0.2.9?

I'm marking as 034-must in case this issue is an 034 regression. If it is, we should fix it before we release 034 stable.

comment:2 Changed 11 months ago by atagar

Thanks teor, I'll try bisecting a bit this weekend. Since this only arises when disconnected I'm not entirely sure when this last worked.

comment:3 Changed 11 months ago by teor

Component: Core Tor/TorCore Tor/Stem
Status: needs_informationnew

I don't think this is a bug in tor.

Tor exits need working DNS, so they check for it on startup, and periodically. If the check fails, they try again. Eventually, they give up and stop being an exit. (For details, see the man page for the options listed below.)

If you don't want this behaviour, set:
ServerDNSDetectHijacking 0
https://gitweb.torproject.org/chutney.git/tree/torrc_templates/relay-non-dir.tmpl#n11

If you want tor exits to work when the resolv.conf file is broken (macOS uses a dangling symlink when offline!), also set:
ServerDNSResolvConfFile /dev/null
https://gitweb.torproject.org/chutney.git/tree/lib/chutney/TorNet.py#n885

comment:4 Changed 11 months ago by atagar

Thanks teor, I was just thinking something similar this morning and getting deja vu (#25852). In several scenarios tor rightfully cannot resolve a complete policy (since 'reject private' requires knowing our own resolved address).

In some cases Stem users care about these details, but in most they simply want a reliable way of getting our policy (with or without 'reject private'). I'll need to give this more thought.

comment:5 Changed 11 months ago by rl1987

Cc: rl1987 added
Keywords: tor-control added

comment:6 in reply to:  3 Changed 11 months ago by teor

Keywords: regression 035-must 034-must tor-control removed
Milestone: Tor: 0.3.5.x-final

Replying to teor:

I don't think this is a bug in tor.

Tor exits need working DNS, so they check for it on startup, and periodically. If the check fails, they try again. Eventually, they give up and stop being an exit. (For details, see the man page for the options listed below.)

If you don't want this behaviour, set:
ServerDNSDetectHijacking 0
https://gitweb.torproject.org/chutney.git/tree/torrc_templates/relay-non-dir.tmpl#n11

If you want tor exits to work when the resolv.conf file is broken (macOS uses a dangling symlink when offline!), also set:
ServerDNSResolvConfFile /dev/null
https://gitweb.torproject.org/chutney.git/tree/lib/chutney/TorNet.py#n885

So this is not a regression, nor is it a bug in Tor.
Untagging.

comment:7 Changed 11 months ago by rl1987

Do we have anything actionable here? Should we close this ticket as 'notabug'?

comment:8 Changed 11 months ago by atagar

Hi rl1987, this ticket is assigned to my component and I plan to take action on my end. In particular I'll be reverting Stem's reliance on 'GETINFO exit-policy/full' to keep its fallback logic for when that option's unavailable.

comment:9 Changed 10 months ago by atagar

Resolution: fixed
Status: newclosed

Reverted reliance on this getinfo option. When unavailable we again use the logic we had prior to this option's addition.

https://gitweb.torproject.org/stem.git/commit/?id=aa17637

Note: See TracTickets for help on using tickets.