Implement SOCKSPort windows:path for named pipes
This is identical to #12585 (moved) SocksSocket except for Windows users wishing to use Named Pipes in this same manner.
Firefox changes to use this (instead of SocksPort) unknown. See https://bugzilla.mozilla.org/show_bug.cgi?id=892114
Trac:
Username: anon
Activity
changed milestone to %Tor: unspecified
This would allow the use of a pipe name (or one at random?) like "\.\pipe\TorSocks" to connect clients to Tor proxy capability with the additional security controls and performance benefits that Named Pipes bring on the Windows platform.
If using a random pipe name (different from an anonymous pipe!) then the ControlPort GETINFO may be required to discover it.
Trac:
Username: anon-
per nickm: "there's going to be trouble with the way that libevent uses windows stuff; you'll need to handle the namedpipes in a separate thread, or hack libevent to do so, writing it a new backend, or both."
The right solution is a good backend for libevent to handle this Win pipe IO. the expedient solution is to hand it off to a thread pair.
Also requiring defition: access control syntax, on pipe itself in configuration option. (This user only, etc.)
Trac:
Username: anon -
per nickm:
I'd suggest an extra thread and event loop to process Windows handles. You'll need to communicate with the main thread; look at workqueue.c to get some idea of how we do that now, though you'd probably want a different implementation. Avoid sharing structures whenever possible. To keep as much shared implementation as possible, you might do it like this:
- enable threadsafe mode when initializing libevent.
- Add handle-based versions of read_to_buf / flush_buf. Use them as appropriate.
- Allow a connection_t to optionally have a handle instead of a socket.
- When constructing the event objects for the handle, do not pass in a file descriptor. Instead, pass a file descriptor of -1.
- From the worker thread, use event_active() to make those event objects active when the handles are ready for read/write. (This is why libevent needs to be running with thread safety enabled.)
- Now all you'll need is some way for the main thread to tell the worker thread about new handles, closed handles, and which of the handles should be reading/writing.
Trac:
Username: xeonchen
Sponsor: N/A to N/A
Severity: N/A to Normal
Reviewer: N/A to N/A This in Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=1288308
Adding some keywords so this ticket can get triage attention.
I think the simple version (socketpair?) would be fine in the shorter term.
The goal here is that when the Firefox folks think about sandboxing networking on Windows, they don't say "oh, Tor doesn't support that, ok we'll skip that idea".
Trac:
Keywords: tor-client needs-libevent-patches hard win32 windows deleted, tor-client needs-libevent-patches hard win32 windows 035-proposed 036-proposed addedmentioned in issue #14210 (moved)
moved to tpo/core/tor#14209 (closed)
mentioned in issue tpo/core/torsocks#14210 (closed)
