Re: PHP4 + ApacheVirtualHosts + SUEXEC
Thank you for the explanation, I now have a much better understanding of how
Apache works. After a bit more digging around on the web I also found this
discussion thread with some responses from Rasmus Lerdorf (regarding php3
and a few years old, but it still seems to be relevant).
http://lists.omnipotent.net/php3/199808/thrd3.html#00464
Now I'm curious as to how Apache 2.0 works and how it deals with these
issues.
Thanks again
eirik
on 1/4/01 4:36 PM, Sickboy at sd209@hszk.bme.hu wrote:
> Eirik Dentz wrote:
>>
>> Nonetheless it leaves me very curious as to why the PHP
>> module is built this way.
>
> I guess it is just the way apache works.
> Having something (anything) as a module means having the code in apache
> itself. Every httpd child process has the code in it.
>
> When you run a CGI, the httpd child process forks and calls suexec.
> (or sbox or any other replacement for suexec in terms of cgi wrapper)
> suexec changes uid/gid, NOT THE HTTPD CHILD PROCESS!
>
> To run a module (e.g. the PHP interpreter built as a module) as another user,
> the httpd child process has to change to the specified uid/gid (!) and then
> back (!).
> If a process can change its uid/gid back to the original uid/gid then it
> hardly makes any sense to change uid/gid at all.
>
> I could imagine a httpd that forks a new child on each new request and the
> child changing to the uid/gid specified for the VW and finally dying when
> the request is processed, but this would probably mean performance issues..
>
> Anyway, it boils down to apache not working this way.
>
>> I've never actually used them so please pardon my ignorance,
>> but does using mod_perl with Mason to embed perl code in
>> HTML cause a similar problem with suexec?
>
> Having said all this, I would say yes.
> (But I've never used/seen this either.)
>
>
> .SiCk of IT.
>
>
> --
> To UNSUBSCRIBE, email to debian-isp-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: