<div>Great idea! This should simplify things quite a lot when using control connections.</div><div><br></div><div>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.</div>
<div><br></div> - John Brooks<br>
<br><div class="gmail_quote">On Sun, Mar 1, 2009 at 3:37 AM, Michael Gold <span dir="ltr"><<a href="mailto:torlists@rilmarder.org">torlists@rilmarder.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi all,<br>
<br>
The attached patch allows tor (0.2.0.34) to automatically authenticate<br>
the client of a Unix-domain control socket, by asking the kernel for the<br>
uid and gid of the remote user. There are still some unresolved issues,<br>
but feedback would be appreciated.<br>
<br>
Unauthenticated connections on Unix-domain sockets are now disabled,<br>
even if no authentication is configured; however, tor will always accept<br>
control connections if the client has the same uid and gid as the server<br>
(regardless of authentication settings). The new config file parameters<br>
"ControlAllowUsers" and "ControlAllowGroups" can be used to allow other<br>
users. Each takes a comma-separated list of user/group names; for<br>
groups, any member of a group (as determined by /etc/group) is accepted.<br>
This is similar to the AllowUsers/AllowGroups settings in openssh.<br>
<br>
The problem I've run into is that the listener socket permissions are<br>
affected by the umask, and Linux won't let users without write<br>
permission connect (apparently other systems ignore the permissions).<br>
The obvious solution of fchmod(fd, 0777) has no effect; other possible<br>
solutions are:<br>
- Use chmod; this would be vulnerable to a race condition if another<br>
user could delete and replace the socket before the chmod, but it<br>
should be okay if there's a warning in the documentation.<br>
- Change the umask temporarily; this would affect all threads, so it's<br>
only an option if filesystem operations are restricted to one thread.<br>
<br>
Any suggestions?<br>
<br>
So far this patch has only been tested on Linux, but it seems to work<br>
fine after manually fixing the socket permissions. Testing on other<br>
Unix-like systems would be helpful, if anyone's interested (run<br>
autoreconf before building it).<br>
<font color="#888888"><br>
-- Michael<br>
</font><br>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2.0.9 (GNU/Linux)<br>
<br>
iEYEARECAAYFAkmqZVQACgkQ+RZl+46r4TdNzgCfdu6TvbQyrNfMWeijKJRpUXjn<br>
1bsAnjPj89471DOj3ho1XF2Fui8YZXP1<br>
=0EF0<br>
-----END PGP SIGNATURE-----<br>
<br></blockquote></div><br>