On Thu, Feb 05, 2004 at 02:55:41AM +0300, Dan Yefimov wrote: > On Wed, 4 Feb 2004, [ISO-8859-15] Andr? Malo wrote: > The matter here is not the trust. The matter is that restrictions inflicted by > server admin shouldn't be able to be avoided by using, for example, the > described trick. This is of course not a vuln, but this is a design flaw that > can have some security implications and should be fixed anyway. > As for mod_perl hijacking. Mod_perl has been designed only to speed up > perl CGI scripts execution unrelated to whether server admin trusts his/her > users or not (and mod_php serves the like objective). Thus under mod_perl > control scripts should be run in the same environment as if they were run in a > common way (by forking, closing all file handles except for connected socket and > executing perl interpreter). This means mod_perl must somehow hide all those > file handles from the script being executed. If mod_perl doesn't do that, it's > not simply a design flaw, but it's also a serious security flaw. I do not believe this is a function of the web server. For example any per script can read in a file that is not contained within the document root, as so long as the process has sufficient priviledges to read the file. Any files that you do not want to be read by the web server should be permissioned as such. You argue that the server admin should be able to set restrictions to the server. Here I agree, however, that restrictive mechanism lies within the filesystem permissions and is not a function of the webserver. When it comes down to it, you are trying to restrict read access for the files in question, why would it be any different than restricting read access for any other user on the system? .tidd.
