On 7/24/08, Fergus Henderson <[EMAIL PROTECTED]> wrote: > On Wed, Jul 23, 2008 at 5:15 PM, Ihar `Philips` Filipau > <[EMAIL PROTECTED]> wrote: > > > My wish then would be to have a magic option (which might also throw > > some warning into logs, to warn the lazy people like me about > > consequences) to disable all security features altogether. e.g. > > --security=off and default --security=on (or whatever popt can > > handle). > > Well, if that's all you need, then it's already supported, with a slightly > different syntax: instead of > > distccd --security=off > > the syntax is > > distccd --allow=255.255.255.255/32
Or in even less characters i think 0.0.0.0/0 will work. iirc this is in the manpage. (I also recall some program that could be compiled with -DGAPING_SECURITY_HOLE if you wanted...) As well as untrustworthy people or compromised machines on corporate networks there are also people on home networks that may be accessible to the outside world. I know of at least one person who has been attacked this way despite the documentation, and there are automated tools that will scan for and attack distcc machines. I did measure using ssh as a transport and it is noticeably slower, even with connection sharing. The precise factor will depend on the relative speed of cpu, memory, etc, but I think it should not be the only way of having a reasonably secure connection. It seems to me that a common situation these days is that there are untrusted machines able to reach the server, but they are not able to intercept traffic. (Maybe this is unrealistic, I suppose intercepting it may be possible with arp spoofing.) In that case just a shared-key or challenge-response authentication would be enough. At least this would defeat public internet scans for distcc servers. If it turns out that most of the features of ssh are needed then it would be better to work out how to use that efficiently than to duplicate it. It would also be interesting, though nontrivial, to take the approach in djb's recent "10 years of qmail" paper and run each individual job in a separate uid. (Somewhat reminiscent of Erlang processes.) Of course this needs some kind of privileged helper. It might also be good for distributors to arrange for distccd to run in a chroot... -- Martin <http://launchpad.net/~mbp/> __ distcc mailing list http://distcc.samba.org/ To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/distcc