[tor-bugs] #1329 [Torctl]: TorCtl Crashes with Invalid torrc

Tor Bug Tracker & Wiki torproject-admin at torproject.org
Mon Jun 13 16:36:52 UTC 2011


#1329: TorCtl Crashes with Invalid torrc
-----------------------+----------------------------------------------------
    Reporter:  atagar  |       Owner:  mikeperry   
        Type:  defect  |      Status:  needs_review
    Priority:  normal  |   Milestone:              
   Component:  Torctl  |     Version:  0.2.1.24    
  Resolution:  None    |    Keywords:              
      Parent:          |      Points:              
Actualpoints:          |  
-----------------------+----------------------------------------------------
Changes (by atagar):

  * status:  new => needs_review
  * priority:  minor => normal


Old description:

> Hi Mike. By issuing a sighup with an invalid torrc (my test case being to
> set RelayBandwidthBurst <
> RelayBandwidthRate) TorCtl dies in a rather unsightly way. Unfortunately
> I can't prevent this in arm, and if
>  TorCtl kills the interpreter while curses is running the user's terminal
> is left in an especially screwed up
>  state (requiring a reset to function again).
>
> Traceback (most recent call last):
> File "/home/atagar/Desktop/arm/TorCtl/TorCtl.py", line 494, in _loop
>   isEvent, reply = self._read_reply()
> File "/home/atagar/Desktop/arm/TorCtl/TorCtl.py", line 636, in
> _read_reply
>   line = self._s.readline()
> File "/home/atagar/Desktop/arm/TorCtl/TorUtil.py", line 198, in readline
>   s = self._s.recv(128)
> error: (104, 'Connection reset by peer')
>

> [Automatically added by flyspray2trac: Operating System: All]

New description:

 Hi Mike. By issuing a sighup with an invalid torrc (my test case being to
 set RelayBandwidthBurst <
 RelayBandwidthRate) TorCtl dies in a rather unsightly way. Unfortunately I
 can't prevent this in arm, and if
  TorCtl kills the interpreter while curses is running the user's terminal
 is left in an especially screwed up
  state (requiring a reset to function again).

 Traceback (most recent call last):
 File "/home/atagar/Desktop/arm/TorCtl/TorCtl.py", line 494, in _loop
   isEvent, reply = self._read_reply()
 File "/home/atagar/Desktop/arm/TorCtl/TorCtl.py", line 636, in _read_reply
   line = self._s.readline()
 File "/home/atagar/Desktop/arm/TorCtl/TorUtil.py", line 198, in readline
   s = self._s.recv(128)
 error: (104, 'Connection reset by peer')


 [Automatically added by flyspray2trac: Operating System: All]

--

Comment:

 There's two issues here both exhibited from the use case above...

 1. The socket encounters a 104 error after a failed reset. I haven't
 managed to repro this without arm but it's trivial to fix.

 2. A failed reset causes TorCtl to freeze. This can be repoed with a
 simple torctl-only use case...
   - start tor with a valid torrc
   - connect torctl
   - screw up the torrc (anything will do)
   - use torctl to send the reset signal (doing a pkill sighup won't
 exhibit this problem)

 {{{
 >>> import TorCtl
 >>> conn = TorCtl.connect()
 >>> conn.send_signal("RELOAD")
 NOTICE[Mon Jun 13 07:29:41 2011]:Tor closed control connection. Exiting
 event thread.
 }}}

 At this point TorCtl hangs until the python process is killed. This second
 issue is because, in _sendImpl line 785:
 https://gitweb.torproject.org/pytorctl.git/blob/HEAD:/TorCtl.py#l785

 we block until we get a reply which never comes since _loop hit the
 exception on line 683:
 https://gitweb.torproject.org/pytorctl.git/blob/HEAD:/TorCtl.py#l683

 I've made a fix for this issue in my 'bug1329' branch which raises the
 TorCtlClosed to the caller:
 https://gitweb.torproject.org/atagar/pytorctl.git/commit/9de33409bb240d8fe50e135dfb895536dc6a45bd

 In all the testing I'm throwing at it this seems to work well, however
 this concurrency handling is pretty confusing so scrutiny welcome. :)

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


More information about the tor-bugs mailing list