From owner-freebsd-isp@FreeBSD.ORG Sat Jul 15 18:11:00 2006 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6FC8216A58D for ; Sat, 15 Jul 2006 18:11:00 +0000 (UTC) (envelope-from b.candler@pobox.com) Received: from rune.pobox.com (rune.pobox.com [208.210.124.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF2D143D45 for ; Sat, 15 Jul 2006 18:10:59 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id DE9E37B345; Sat, 15 Jul 2006 14:11:20 -0400 (EDT) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id 6B7187B32C; Sat, 15 Jul 2006 14:11:18 -0400 (EDT) Received: from lists by mappit.local.linnet.org with local (Exim 4.61 (FreeBSD)) (envelope-from ) id 1G1obO-00043Y-Bl; Sat, 15 Jul 2006 19:10:54 +0100 Date: Sat, 15 Jul 2006 19:10:54 +0100 From: Brian Candler To: Mark Bucciarelli Message-ID: <20060715181054.GA15489@uk.tiscali.com> References: <20060714195603.GE396@rabbit> <20060714202233.GF396@rabbit> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060714202233.GF396@rabbit> User-Agent: Mutt/1.4.2.1i Cc: freebsd-isp@freebsd.org, David Rhodus Subject: Re: CGI apps in C? X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2006 18:11:00 -0000 On Fri, Jul 14, 2006 at 04:22:34PM -0400, Mark Bucciarelli wrote: > Do you have a link to any of the apps you use? http://www.muquit.com/muquit/software/Count/Count2.6/Count.html is an example of how *not* to write a C cgi :-( Unfortunately, I had to port it from an old webserver to a new one, for compatibility reasons. The biggest pain with C CGIs is that you simply cannot trust any data provided by the caller, and so you must be very careful about not making any assumptions about the format of data which could cause you to end up making a buffer underflow or overflow. This is in addition to the security checks you would have to do for a perl/php type of CGI (such as making sure that data to construct a filename doesn't contain /../, making sure that HTML and SQL special characters are properly escaped, making sure that if you fork a shell, that shell metacharacters are properly defanged, and so on) Another poster suggested using FastCGI. Whilst FastCGI is an excellent framework for web applications, it does not work well for the sort of 'shared' CGIs you're talking about (formmail, counter etc). That's because generally you want these CGIs to run as the UID of the website which is being accessed - in particular to prevent one site's CGI from being able to modify content in a different site's webspace. FastCGIs are persistent, and so run as whatever UID originally started them. So unless you want a whole bunch of FastCGI process pools running around, one for each website, then a single-shot traditional CGI (which can be run under suexec) is much better. The same issue arises with mod_perl and mod_php, where the applications all run as the webserver's own UID. For a single-shot CGI which is exec'd for each request, a C app has a far lower startup overhead than starting a heavyweight scripting language interpreter like Perl. OTOH, there are many other bottlenecks you may reach on your webserver before CGI requests from counters and formmail become significant at all. Much better to monitor your utilisation and logs carefully. Another thing I did was to modify suexec so that it would fork(), wait4(), and then log the rusage information for each CGI execution. Analysing these logs lets you work out, site by site, which are the CGI hogs. But before you start modifying something as security critical as suexec, you'd better be very sure of your C and Unix. Regards, Brian.