Patch to authenticate by uid/gid on ControlSocket

John Brooks special at dereferenced.net
Sun Mar 1 17:47:03 UTC 2009


Great idea! This should simplify things quite a lot when using control
connections.

I'm surprised fchmod doesn't work, but I don't think using chmod() would be
a problem here. Another user very likely wouldn't have the permissions to
replace the socket file, and if they did, the chmod() call would then fail
as the tor user would not own the new file. If they were already running as
the tor user, they could do all sorts of other things and make it really a
moot point anyway. I don't see a way that another user could bother tor
using that race condition.

 - John Brooks

On Sun, Mar 1, 2009 at 3:37 AM, Michael Gold <torlists at rilmarder.org> wrote:

> Hi all,
>
> The attached patch allows tor (0.2.0.34) to automatically authenticate
> the client of a Unix-domain control socket, by asking the kernel for the
> uid and gid of the remote user.  There are still some unresolved issues,
> but feedback would be appreciated.
>
> Unauthenticated connections on Unix-domain sockets are now disabled,
> even if no authentication is configured; however, tor will always accept
> control connections if the client has the same uid and gid as the server
> (regardless of authentication settings).  The new config file parameters
> "ControlAllowUsers" and "ControlAllowGroups" can be used to allow other
> users.  Each takes a comma-separated list of user/group names; for
> groups, any member of a group (as determined by /etc/group) is accepted.
> This is similar to the AllowUsers/AllowGroups settings in openssh.
>
> The problem I've run into is that the listener socket permissions are
> affected by the umask, and Linux won't let users without write
> permission connect (apparently other systems ignore the permissions).
> The obvious solution of fchmod(fd, 0777) has no effect; other possible
> solutions are:
>  - Use chmod; this would be vulnerable to a race condition if another
>   user could delete and replace the socket before the chmod, but it
>   should be okay if there's a warning in the documentation.
>  - Change the umask temporarily; this would affect all threads, so it's
>   only an option if filesystem operations are restricted to one thread.
>
> Any suggestions?
>
> So far this patch has only been tested on Linux, but it seems to work
> fine after manually fixing the socket permissions.  Testing on other
> Unix-like systems would be helpful, if anyone's interested (run
> autoreconf before building it).
>
> -- Michael
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
>
> iEYEARECAAYFAkmqZVQACgkQ+RZl+46r4TdNzgCfdu6TvbQyrNfMWeijKJRpUXjn
> 1bsAnjPj89471DOj3ho1XF2Fui8YZXP1
> =0EF0
> -----END PGP SIGNATURE-----
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20090301/f4f40546/attachment-0001.htm>


More information about the tor-dev mailing list