Hello Joel Palmius, Thursday, July 31, 2003, 3:12:02 PM, you wrote:
JP> This is something I asked before, like one or two years ago. I just want JP> to see if a solution has come up since then. JP> The problem is that with the normal (linux-distro) installation of apache JP> and mod_perl, all processes for all active scripting (cgi, perl, PHP..) JP> run as the same user. Thus, if I run a mod_perl app which keeps a data JP> repository in a file, then that file need to grant write permissions to JP> the web user. If there are untrusted users with access to PHP on the JP> system, then this becomes a problem, since they could easily overwrite JP> that file with a simple script. JP> One may ask why untrusted users should have access to PHP, but this is JP> often the case with student servers in academics, specifically in computer JP> science. JP> The question is, what is the state-of-the-art approach for protecting data JP> written to a file by mod_perl from being overwritten by an untrusted user? JP> Is it possible to run all mod_perl things as a separate user (without JP> having to keep two parallel apache installations)? Not sure what you meant about 'two parallel apache installations' but anyway. We have real working internet solution which I think safe enough. Even we do not use any content generating approaches other than mod_perl I think our solution will work with them. We have one DSO (linux) manually compiled apache whith two (actually more) config files (DSO to avoid two binaries). One for external proxy-cache apache. And one or more for internal real working-horse apaches. We start external proxy to serve static content and dispatch requests to the internal processes which serves dynamic content (we call it application servers). Proxy run under nobody and application server run under user which has enough rights to open/read/write private resources. Usually this is normal OS user and application server has ServerRoot=$HOME of this user. So with backend app server no priviledges conflict and resources is not world writable. Proxy listen internet connections and app servers has no access from internet. Actually things more complicated, but I thik I was clear in our approach. -- WBR, Mike P. Mikhailov mailto: [EMAIL PROTECTED] ICQ: 280990142 You're much more likely to be knocked down by a snowball than by an equivalent number of snowflakes.
