| Also, my system has cgiexec (does suid for CGI scripts) installed. The
| cgiexec documentation says that once cgiexec is installed, it is a
| security risk if people can execute code as "nobody" since that user has
| special access to the cgiexec code. Right now, anyone can execute code as
| nobody by writing ASP code, so in essence I have a security hole in my
| system, and I DO need cgiexec.
Like I said, doing something like suEXEC will solve your file access
problems, but it won't prevent people from messing up things like the
$Session and $Application objects which are accessible to all users running
their site on this webserver. It won't even prevent a user to redefine a
scalars, subroutines or even complete modules which are not belonging to
their own scripts.
This would open up a whole new security hole, because then someone can, with
some smart work, insert handlers or redefine modules which aren't theirs and
then let the code be executed later as someone else with full access to
*all* files of victim.
One way or the other, you are not going to get the security you want.
And then again: if you just think how easily badly coded perl scripts (which
will work perfectly fine as a strict CGI) can become a major pain in the ass
(memory leakage, resource exhaustion) in a mod_perl environment, I wouldn't
trust anybody without prior verification of their coding abilities in such a
virtual hosting environment in the first place.
| So, does anyone have suggestions on how to do suid for ASP scripts?
For the occasional script where you *have* to do suexec because you're going
to have to write to disk, make them plain CGI (that is, with
#!/usr/bin/perl-thing on the first line) and use the Apache suexec.
Otherwise, rethink your concept and see what can be put in a real database.
| Wouldn't this require running one web server process for each user? I may
| be wrong, but it seems to be simpler to just suid their scripts.
Yep. But that's the only way you are going to have a real secure setup.
Ime
