Re: FastCGI and mod_perl compared

[z0d]

in reply to FastCGI and mod_perl compared

One thing for mod_perl: if Your script has a security hole, the attacker can own Apache. In mod_fastcgi, he can only own that process.

Unfortunatelly mod_perl has some memory leaks. mod_perl and mod_fastcgi are different in the way they work. It is up to the developer to choose one of them. mod_perl is faster, mod_fastcgi is more secure.

-- 

<-- z0d -->

[jepri]

I don't understand what you are saying here. Apache forks to child processes. So 'owning' Apache only means you 'own' an Apache child process, which sounds a lot like 'owning' a mod_fastcgi process.

If Apache has been set up by someone who isn't a complete retard it will be suiding to an unprivilidged user the moment it gets a connection request. On most systems this user will be the 'nobody' or 'www-data' user.

Probably the best you could do with one of those accounts is read the source code to the CGI scripts, and if your scripts are programmed correctly then you are safe.

In short, mod_perl is secure, just like mod_ anything is. The memory leaks are another story.

____________________
Jeremy
I didn't believe in evil until I dated it.

[blakem]

I believe z0d was indirectly refering to the fact that FastCGI can be configured to run as different uids for different users. This is similiar to the suexec functionality of regular CGI programs. I know someone who chose FastCGI over mod_perl for this reason at a webhosting site. Multiple unrelated users have less of a chance to step on each others toes this way.

So, its not a question of compromising my mod_perl process vs. my fastcgi process... Its a matter of limiting others security holes from becoming my problem.

p.s. I'm a mod_perl guy myself... but I couldn't refute this aspect when my friend told me about his webhosting gig.

-Blake