[tor-bugs] #6948 [Tor bundles/installation]: Shared memory for zygote mind meld

Tor Bug Tracker & Wiki torproject-admin at torproject.org
Sun Sep 23 20:19:03 UTC 2012


#6948: Shared memory for zygote mind meld
--------------------------------------+-------------------------------------
 Reporter:  ioerror                   |          Owner:  erinn
     Type:  enhancement               |         Status:  new  
 Priority:  normal                    |      Milestone:       
Component:  Tor bundles/installation  |        Version:       
 Keywords:                            |         Parent:       
   Points:                            |   Actualpoints:       
--------------------------------------+-------------------------------------

Comment(by ioerror):

 Replying to [comment:1 arma]:
 > Sounds plausible to me. The first catch that comes to mind is that when
 Tor dies it needs to take down the shared memory hunk too -- and if it
 dies poorly, it might not be able to.

 I was considering this last night and I thought of a possible solution to
 this problem.

 We can ensure that the shared memory hunk has a pointer to a name of
 another shared memory hunk. If Tor goes down without taking down the
 shared global memory mutex, and an application cannot connect, the
 application with this zygote support can check the contents of the shared
 memory for an item that tells them where to create a new shared memory
 mutex. The zygote may then create a new tor instance, which will look at
 the previous instance, grab the old mutex name, increment to the next one
 or use the one left by the first Tor and start a fresh Tor. In this way,
 we can be sure that Tor will always have left a linked list behind that
 leads to a possible new Tor.

 In essence tor-shim-000 will have a few points of application contact
 (ControlSocket, SocksSocket, SocksPort, TransPort, etc) and then other
 information that might be useful (pid of Tor, time of launch, pointer to
 next shared memory address in case this Tor dies badly, etc) to the
 zygote, to other applications and so on.

 This should solve our auto-configuration problems and because we'll have
 security contexts, we can do SOCKS isolation on the SocksSocket by
 uid/gid, we can do security controls with uid/gid on the ControlSocket
 (and still freely share it), we can give out the pid without having to
 resort to some un-portable nightmare and so on.

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


More information about the tor-bugs mailing list