[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 andrea):

 Hmm, sounds like I'm going to be revising this before #11485 then, since I
 wanted to branch that off this to avoid duplicating any AF_UNIX code.

 Replying to [comment:43 nickm]:
 >
 > Throughout:
 >
 >   * Looks nice!  Much simpler now.
 >
 >   - 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 haven't got any Windows anything set up; might be best if you do this.

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

 I can't say I like it all that much either but I'm drawing a blank
 thinking of anything else.

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

 Okay.

 > 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"?

 Okay.

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

 These both sound like good ideas.

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

 Hmm...

 >   - 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.
 >
 > relay.c:
 >
 >   - Same comment as comment above, wrt the change in
 >     connection_edge_process_relay_cell_not_open().
 >
 >
 > Otherwise, looks okay.  Have we tested the latest version of this? :)

 Yeah, tested last night using socat to forward incoming TCP connections to
 AF_UNIX and it worked great.

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