[tor-bugs] #12585 [Tor]: Implement new option SocksSocket

[Tor Bug Tracker & Wiki]

#12585: Implement new option SocksSocket
-----------------------------+--------------------------------
     Reporter:  ioerror      |      Owner:
         Type:  enhancement  |     Status:  needs_revision
     Priority:  normal       |  Milestone:  Tor: 0.2.6.x-final
    Component:  Tor          |    Version:  Tor: unspecified
   Resolution:               |   Keywords:  026-triaged-1
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+--------------------------------

Comment (by ioerror):

 Replying to [comment:43 nickm]:
 >
 > Throughout:
 >
 >   * Looks nice!  Much simpler now.

 Agreed - a lot of refactoring that makes it easier to read!

 >
 >   - This is probably gonna break on windows: I don't think they have
 AF_UNIX, and at least address.c uses AF_UNIX unconditionally. I can clean
 it up if you want, or you can if you've got mingw cross-compilation stuff
 installed.

 I think it would be great if anyone with Windows could make this work. It
 would remove lots of local firewall issues, I think. I think the proper
 way to implement it would be to use a named pipe (
 http://msdn.microsoft.com/en-
 us/library/windows/desktop/aa365590%28v=vs.85%29.aspx ) and it would
 effectively be the same feature.

 >
 >   - Is "SocksSocket" really the right name for this?  I'm used to  it,
 but I bet it would confuse users some.

 I'm partial to the name but I'm open to bikesheds. :-) Other thoughts on
 names:

   SocksPipe
   SocksSocket
   SocksUnixSocket
   PipeProxy
   PipeSocksTransport
   SocksFile
   SocksSandbox

 Any other ideas welcome :)

 >
 > address.c
 >
 >   - Probably should document how to work with unix domain sockets;
 >     they don't actually fit in a tor_addr_t.


 >
 > config.c / tor.1.txt
 >
 >   - Can we support SocksSocket on-by-default?  If so we'd need a way
 >     to turn it off.  "SocksSocket 0"?

 I think if we can enable SocksSocket by default, we'd want a way to turn
 it off, yes. Perhaps a totally new option? Perhaps we want to have a
 different ticket for enabling it by default where we add a SocksSocket
 kill switch?

 >
 > connection.c:
 >
 >   - I wonder if we should try fchmod first, and then chmod.  fchmod
 >     is a bit safer, right?  (Not a new issue.)

 I'm not familiar with this - Andrea, any thoughts?

 >
 >   - If we chmod 0660 in the event of a group-writable socket, should
 >     we shmod 0600 in the event of a non-group-writable socket?
 >     (Not a new issue.)

 Same as above.

 >
 >   - The foosocketsgroupwriteable code in connection_listener_new
 >     seems to be nearly duplicated.
 >

 Yes, I think that is true

 >   - This comment is wrong:
 > {{{
 >     /* For now only control ports can be Unix domain sockets
 >       * and listeners at the same time */
 > }}}
 > connection_edge.c:
 >
 >   - What's the point of the modifications of
 >     connection_ap_get_begincell_flags and
 >     connection_ap_handshake_rewrite_and_attach ?  I think they might
 >     be wrong.   The flags that they adjust are about whether the
 >     destination address is IPv4/IPv6/etc, not whether the socksport
 >     address is IPv4 or IPv6.

 Interesting. I think this is a mistake, then.

 >
 > relay.c:
 >
 >   - Same comment as comment above, wrt the change in
 >     connection_edge_process_relay_cell_not_open().
 >

 Perhaps a second bug? Andrea - what do you think?

 >
 > Otherwise, looks okay.  Have we tested the latest version of this? :)

 I haven't tested the latest version. I'd like to get the final patch ready
 for testing and then I'll gladly test it. Though I suspect it would be
 *really* useful if someone else *also* tested it and confirmed it worked.
 Especially on OS X!

 In some kind of ideal world, I like the idea of shipping TBB with Firefox
 completely sandboxed from making TCP/IP connection on two of our three
 platforms. The third one being windows, of course. I guess that depends on
 discovering if NamedPipes will work or not.

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