On Sat, 6 Nov 2004 16:55:33 +0100, Lukas Ruf <[EMAIL PROTECTED]> wrote: > > If they got Apache to execute the script, the "bad_command" would be > > run. This is the reason why I'm trying to approach this problem from > > a permissions standpoint. Of course, someone might suggest running > > an Apache daemon inside each user's chroot, but that's really > > impractical... > > > > if apache is run in a chroot'ed environment, wouldn't this solve > exactly the problem? I run my "public" web-server that way together > with the suexec feature enabled such that a script is executed as the > owner of the directory/user, hence I feel pretty safe in that regard.
I'm running Apache in a virtual-hosting environment with multiple users. If I understand Apache chroot'ing correctly, that would mean I would have to run a different Apache process for every user (one Apache process per each user's chroot), and that would only be the minimum number of Apache processes I would have to be running. As you can see, as the number of users grow and the traffic to each of their websites increases, the number of independent Apache processes running could get out of hand. However, suEXEC looks like the tool I need to ensure that a user's Perl scripts run with their priviledges and not Apache's. Do you know if suEXEC would also apply to PHP scripts? Thanks, Stephen Le -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
