Re: Patch to authenticate by uid/gid on ControlSocket

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.

On Sun, Mar 1, 2009 at 3:37 AM, Michael Gold <torlists@xxxxxxxxxxxxx> 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-----