CGI apps in C?

[Brian Candler]

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.