Opened 8 years ago

Closed 4 years ago

#5085 closed defect (duplicate)

managed obfsproxy does not quit if tor dies

Reported by: arma Owned by: asn
Priority: Low Milestone:
Component: Archived/Obfsproxy Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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?

Child Tickets

Change History (8)

comment:1 Changed 8 years ago by 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=<PID> 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.

comment:2 in reply to:  1 Changed 8 years ago by rransom

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=<PID> 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.

comment:3 Changed 8 years ago by arma

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.

comment:4 Changed 6 years ago by asn

Parent ID: #10047

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

comment:5 Changed 5 years ago by dcf

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), 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.

comment:6 Changed 5 years ago by yawning

Parent ID: #10047

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

comment:7 Changed 4 years ago by arma

Severity: Normal

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

comment:8 in reply to:  7 Changed 4 years ago by dcf

Resolution: duplicate
Status: newclosed

Replying to arma:

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

Closed!

Note: See TracTickets for help on using tickets.