3 ms·
I'm aware, but maybe I didn't phrase my question well. CGI scripts, including PHP when run in that mode, fork a new process as the appropriate user - as you say
by ptx 7y ago
I'm aware, but maybe I didn't phrase my question well. CGI scripts, including PHP when run in that mode, fork a new process as the appropriate user - as you say.
But mod_php runs in the Apache process instead, for better performance. What I'm not sure about is whether it changes the user somehow when handling the request or just runs everything as the Apache user. I believe it's the latter since I've seen various modules that claim to address the problem.
- tpetry 7y agoEverything was/is run as the apache user. PHP tried to make it secure by restricting the folders a script was allowed to access but over the years so many ways to break had been found that a fastcgi process per user showed its the best solution. I think the system was called basedir restriction.
- chubot 7y agoYeah that's true, I misunderstood. He did mention in the talk that mod_perl was infeasible for this use case because it gave the user too much control. One user could override the Apache base_dir and redirect another user's traffic to his pages!!! He said that as a result, hosting providers in the 90's would charge 100x the price for mod_perl hosting on a dedicated bare metal box, vs mod_php which could be shared. Didn't know that. So I guess the answer is that mod_php has to be careful and not expose too many Apache hooks to the user. The PHP interpreter does seem to have some unique qualities that make it good for embedding, compared with Perl, Python, Ruby.