CGI apps in C?

[Mark Bucciarelli]

On Sat, Jul 15, 2006 at 07:10:54PM +0100, Brian Candler wrote:

> 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)

"fork a shell"

This would be used if you want to run "find" or some other shell
utility from your C code.  Correct?

> 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.

Yes, I did a bunch of reading when setting up my first FreeBSD
server and settled on running PHP apps using fastcgi + suexec.
Very RAM-heavy, as each client get's their own php interpreter
resident.  They time out pretty fast, which is good for RAM but
bad for the next time someone visits the site.  There is no
better solution I have found for performance + security with PHP.
And I don't like it much ... hence my initial post.

> 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. 

That sounds pretty interesting.  Did you publish your work?

> But before you start modifying something as security critical
> as suexec, you'd better be very sure of your C and Unix.

I'm sure of my C, but still learning Unix.

Thanks for all the replies!

m