[tor-bugs] #10088 [Tor]: Allow tor helpers to use JobObjects by setting CREATE_BREAKAWAY_FROM_JOB (Windows-only)

[Tor Bug Tracker & Wiki]

#10088: Allow tor helpers to use JobObjects by setting CREATE_BREAKAWAY_FROM_JOB
(Windows-only)
------------------------+--------------------------------
     Reporter:  asn     |      Owner:
         Type:  defect  |     Status:  new
     Priority:  normal  |  Milestone:  Tor: 0.2.4.x-final
    Component:  Tor     |    Version:
   Resolution:          |   Keywords:  tor-pt
Actual Points:          |  Parent ID:
       Points:          |
------------------------+--------------------------------

Comment (by infinity0):

 Thinking about this some more, I'm not sure that this ticket is even
 necessary.

 [http://msdn.microsoft.com/en-
 us/library/windows/desktop/ms684863%28v=vs.85%29.aspx MSDN] says:

 > CREATE_BREAKAWAY_FROM_JOB 0x01000000
 > The child processes[A] of a process[B] associated with a job are not
 associated with the job.
 > If the calling process[C] is not associated with a job, this constant
 has no effect. If the calling process is associated with a job, the job
 must set the JOB_OBJECT_LIMIT_BREAKAWAY_OK limit.

 There are two ways of interpreting this:

 1. C is the process that calls CreateProcess (e.g. Tor), B is the child
 process (e.g. the PT), and A is the grandchild (e.g. the PT's helper)
 2. C is the process that calls CreateProcess (e.g. Tor), B is also this
 process, and A is the child (e.g. the PT)

 As it turns out, (2) is the correct interpretation. From
 [http://read.pudn.com/downloads119/ebook/504532/Programming.Applications.for.Microsoft.Windows.4thEd.Jeffrey.Richter.pdf
 this 3rd-party book]:

 > To make [a newly spawned process ... execute outside the job], you must
 call CreateProcess with the new CREATE_BREAKAWAY_FROM_JOB flag. If you
 call CreateProcess with the CREATE_BREAKAWAY_FROM_JOB flag but the job
 does not have the JOB_OBJECT_BREAKAWAY_OK limit flag turned on,
 CreateProcess fails. This mechanism is useful if the newly spawned process
 also controls jobs.

 In other words, it doesn't matter if obfs-flash is part of a job (as this
 ticket tries to prevent); all that matters is that the children aren't
 part of the same job (which it accomplishes by setting the flag on its own
 children).

 I believe that the reason we opened this ticket, was an incorrect mixed
 interpretation of both (1) and (2), and actually the real fix that enabled
 dcf's tests to work was in [ticket:10006#comment:23] where I removed the
 "overengineered workaround" - previously, I was only setting the flag
 conditionally in the subproc tests, but now I am doing it everywhere,
 including when obfs-flash spawns its children.

 If my suspicion is correct, then dcf if you run your tests from
 [ticket:10006#comment:28] with a pristine unhacked tor.exe, it will still
 work. (I don't have access to a Vista/7 machine to do this test myself.)

 In other words, the original intent of this ticket (simply setting the
 flag) is pointless, because Tor is not using JobObjects. However, if this
 flag is set *together with* the "optional addition" I mentioned in the
 previous comment, then we do achieve something - namely the behaviour
 that, if Tor crashes, the child PTs die too. (At the moment this doesn't
 happen with our Python JobObjects, since that is done in the PT and so
 implements the behaviour "if the parent PT dies, the child sub-PTs die
 too".)

 Apologies for the noise.

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