Hello,
GRBy looking the way modperl works today, it's clearly it were not
GRdesgined to SECURELY support a multi-user environment. For instance: Any
GRuser can write a script that will be able to read any file owned by the
GRhttpd server, in a multi-user environment it should not be allowed.
This is a general Unix webserver issue and not specific to mod_perl, so
I've marked your message [OT] for off-topic.
You cannot easily avoid this problem in general.
(1) HTTP requests can come from anybody.
(2) All HTTP requests are serviced by the same webserver.
(3) The webserver needs to be able to read and execute scripts.
Therefore, in general if untrusted users can write webserver executed
scripts, they can read anything the webserver can.
GRA gentle way to prevent this would be not to allow a script read a file
GRwhose owner id is not the same from the script owner id, isn't it?
This is fine, but you're talking about revamping Unix permissions here,
not at the webserver level. The webserver cannot enforce this condition
because the webserver only runs the script, it is not the OS that the
script runs on.
GRAnother problem: process creation should be wrapped by apache suexec
GRmechanism, is it currently done this way? Why not?
This could help sidestep the issue. It is not done this way by default,
because even using suexec doesn't automatically make your scripts secure,
and in fact it can make the situation worse.
GRMay some here confirm me that if i am a security concious admin, i
GRshould not make modperl+embperl available to my user?
If you are a security conscious admin, and you cannot trust your users,
you should not make mod_perl available to them. In fact you should not
make any dynamic HTTP functionality available to them--CGI, ISAPI,
FastCGI, or anything else.
Humbly,
Andrew
--
Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED]
Engineer [EMAIL PROTECTED] Voice 650-930-9062
Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101
--
