Bug #1435
closedfcgi spawn or chroot mistiming
Description
I came across this while porting over to this version. I run all servers in chroot jails as underprivileged users, yet before I had fixed the lib dependaicies in the jailed root I noticed I was able to successfully bring up the webserver and its requisite php fcgi with no problems. This is broken, as upon chrooting into my jail php fails to start on libs just as I would expect it to. Is php being fired up before chrooting? Is the lighttpd silently failing to go chroot? It seems to be dropping privilages fine. Ideas?
Updated by jrabbit over 16 years ago
Version 1.5.0 no longer spawns PHP - it only connects to an independent PHP fastcgi server. You can use the spawn-fcgi program that comes with lighttpd to launch a copy of PHP that lighttpd will connect to.
Updated by Anonymous over 16 years ago
Replying to jrabbit:
Version 1.5.0 no longer spawns PHP - it only connects to an independent PHP fastcgi server. You can use the spawn-fcgi program that comes with lighttpd to launch a copy of PHP that lighttpd will connect to.
Does this also refer to 1.4.18? Perhaps I misphrased the situation: somehow a fastcgi php is getting invoked (creating sockets in /tmp). Lighttpd is supposed to be running chroot in /jaildir. There are not sockets in /jaildir/tmp. Somehow the lighttpd that is supposed to be chrooted into /jaildir is able to communicate to these sockets in /tmp (I'm guessing this is how lighttpd talks to a fastcgi php) What could be causing this?
I haven't explicitly started anything php ever and I wrote the startup files for the server, so I don't understand how a fastcgi server would already be running. Some more information:
I have two jails:
/opt/kwur/externalroot
/opt/kwur/internalroot
Each jail has its own PHP-5.2.4 and lighttpd that was --prefix'd into that directory. Each jail has the appropriate libs as determined by ldd. There is also a global PHP 5.2.4 that I use for running scripts installed into /usr/local, and it is this PHP that would have access to /tmp and it seems that it is this PHP that lighttpd is managing to start when it should not be able to.
Updated by jrabbit over 16 years ago
Sorry - I saw milestone 1.5.0 and mistook it for the version. However, I used to use the spawn-fcgi script in 1.4 as well even, though it was optional in that version and lighttpd could spawn its own php. Using the external service gives you a way to ensure the php fastcgi service runs inside the jail. It also means you can restart it independently of lighttpd.
Updated by Anonymous over 16 years ago
You can close this! netstat lists /tmp/whatever but it is mistaken, the sockets do reside in the proper jail! No problems, sorry for troubling all of you!
Updated by darix over 16 years ago
- Status changed from New to Fixed
- Resolution set to invalid
Also available in: Atom