managed obfsproxy does not quit if tor dies

If Tor crashes, a managed obfsproxy sticks around. That's not so bad, because Tor isn't supposed to ever crash. But shouldn't we have defense-in-depth here?

added component::archived/obfsproxy owner::asn priority::low resolution::duplicate severity::normal status::closed type::defect labels

So, to do that we need to pass obfsproxy the pid of Tor on startup, because if we don't, we can't learn it reliably in a portable way afaik. We can then use the procmon thing that we have in Tor, ported over. That's ugly and insane, but maybe our best alternative?

To pass the pid, we could invent something like passing a --managed= to obfsproxy, and in the torrc specify a certain magic string to mean "pass whatever pid we have". I think that should work, and it would be the cleanest alternative I can think of.

Replying to Sebastian:

So, to do that we need to pass obfsproxy the pid of Tor on startup, because if we don't, we can't learn it reliably in a portable way afaik. We can then use the procmon thing that we have in Tor, ported over. That's ugly and insane, but maybe our best alternative?

To pass the pid, we could invent something like passing a --managed= to obfsproxy, and in the torrc specify a certain magic string to mean "pass whatever pid we have". I think that should work, and it would be the cleanest alternative I can think of.

Put it in the environment! We're cramming everything else a managed proxy needs to know into that blivet; another few bytes can't hurt.

I think it's not urgent to get a fix for this in, if it involves a whole lot of code, assuming it really only happens when Tor crashes. We should fix the Tor crashes in that case.

Apparently twilde saw it happen on a normal Tor exit though? If that's the case then there's a Tor bug there too.

#10047 (moved) might be able to help with this. I'll mark this as a child of #10047 (moved) , since #10047 (moved) already has a parent.

Trac:
Parent: N/A to #10047 (moved)

I had to solve this problem for meek-client-torbrowser on Windows. meek-client-torbrowser starts two of its own subprocesses, and on Windows, tor kills its PTs uncleanly with TerminateProcess (#9330 (moved)), hence they don't have a chance to clean up their subprocesses.

What I did was described in comment:5:ticket:10047. You stick another process (called terminateprocess-buffer) in between tor and the real PT (meek-client-torbrowser). tor kills terminateprocess-buffer uncleanly. The real PT senses that its stdin has closed, and uses that as a signal to shut down cleanly.

How this would work in the obfsproxy case is you would put the buffer process in between tor and obfsproxy, and modify obfsproxy to monitor the closedness of its stdin.

The buffer source code looks like this: https://gitweb.torproject.org/pluggable-transports/meek.git/blob/ff595f26a6be2c4ca58637e04c012b804e69617e:/terminateprocess-buffer/terminateprocess-buffer.go.

Unfortunately, tor closes the stdin of its PT processes on startup, so the PT has to know whether it is being run with a terminateprocess-buffer or not, and interpret the closing of stdin appropriately. In meek-client-torbrowser, this is done with a special --exit-on-stdin-eof option.

#15435 (moved) supercedes #10047 (moved), and #15471 (moved) should help a lot here at least on Linux.

Trac:
Parent: #10047 (moved) to N/A

Ok to close this ticket, maybe even as a duplicate of #15435 (moved)?

Trac:
Severity: N/A to Normal
Sponsor: N/A to N/A
Reviewer: N/A to N/A

Replying to arma:

Ok to close this ticket, maybe even as a duplicate of #15435 (moved)?

Closed!

Trac:
Status: new to closed
Resolution: N/A to duplicate

closed

mentioned in issue #15434 (moved)

mentioned in issue #15435 (moved)