Re: CGI apps in C?

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
_______________________________________________
freebsd-isp@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isp
To unsubscribe, send any mail to "freebsd-isp-unsubscribe@xxxxxxxxxxx"

Relevant Pages