[tor-bugs] #2972 [Tor Client]: Allow ControlSocket to be group writable

Tor Bug Tracker & Wiki torproject-admin at torproject.org
Tue Apr 26 20:28:44 UTC 2011


#2972: Allow ControlSocket to be group writable
-------------------------+--------------------------------------------------
 Reporter:  lunar        |          Owner:                    
     Type:  enhancement  |         Status:  needs_review      
 Priority:  normal       |      Milestone:  Tor: 0.2.2.x-final
Component:  Tor Client   |        Version:  Tor: unspecified  
 Keywords:               |         Parent:                    
   Points:               |   Actualpoints:                    
-------------------------+--------------------------------------------------

Comment(by nickm):

 Replying to [comment:9 rransom]:
 > Replying to [comment:8 Sebastian]:
 > > Replying to [comment:7 nickm]:
 > > > I like this idea, but think that depending on the default group
 seems error-prone.  Perhaps instead of a boolean, it could take the name
 of a group, and chgrp the socket before doing the chmod?  That seems less
 likely to wind up with surprising results.
 > >
 > > Do you think the same applies to the case of cookie auth?
 >
 > I don't think relying on the default group is error-prone at all.  Tor's
 documentation states that it when it is started as root and the User
 option is specified, it changes to that user ID and the default group
 associated with that user ID; that appears to work correctly on Linux
 2.6.x with glibc and FreeBSD 8.2-RELEASE-p1.

 I'm not saying it's error-prone because of a lack of documentation; I'm
 saying it's error-prone because it's not too hard for people to get
 confused about which group is in fact the default group for a given user
 at a given time.  If you think you've set it up so that you're running as
 user=tor group=tor but in fact you're running as user=tor group=users,
 then you're in deep trouble.  Specifying the group explicitly makes this
 kind of error basically impossible to do.

 > > > Finally, the linux unix(7) manpage says:
 > {{{
 > Connecting  to  the
 >        socket  object  requires  read/write permission.  This behavior
 differs
 >        from many BSD-derived systems which ignore permissions for  Unix
 sock‐
 >        ets.  Portable programs should not rely on this feature for
 security.
 > }}}
 > > >
 > > > Is this true nowadays?  If so, we shouldn't give people a false
 sense of security by allowing this option where it won't work.
 >
 > Part of the reason I started using FreeBSD was so that I could test that
 fact.  I haven't tested it or RTFSed yet, but the
 [http://www.freebsd.org/cgi/man.cgi?query=unix&apropos=0&sektion=4&manpath=FreeBSD+8.2-RELEASE&format=html
 unix(4)] and
 [http://www.freebsd.org/cgi/man.cgi?query=connect&apropos=0&sektion=2&manpath=FreeBSD+8.2-RELEASE&format=html
 connect(2)] man pages seem to say that FreeBSD currently does not allow
 users without write access to a local socket to connect to it.
 >
 > > We should probably disable the !ControlSocket option altogether on
 such systems, or at least warn loudly when it is used?
 >
 > There is enough FUD out there about whether filesystem permissions on
 local sockets are enforced that I would recommend removing the
 !ControlSocket option.  It isn't even reliably possible to determine which
 kernel a compiled executable is running on anymore.

 Well, we could always make a socket at runtime, give it permissions 000,
 and then try to write to it.  :/

 Personally I want to know which live systems actually have this problem
 before we remove a feature based on some kernels not doing it right.

 I'm attaching a pair of test programs that should compile on most unixes.
 One verifies that we honor mode 000 on AF_UNIX sockets; the other verifies
 that we check permissions in the directory path when connecting to AF_UNIX
 sockets.  If we can find extant tor-supported platforms where the answer
 is "no", that's something we should act on.

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


More information about the tor-bugs mailing list