Project

General

Profile

Bug #1435

fcgi spawn or chroot mistiming

Added by Anonymous almost 12 years ago. Updated almost 11 years ago.

Status:
Invalid
Priority:
Normal
Assignee:
-
Category:
core
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Missing in 1.5.x:

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?

History

#1

Updated by Anonymous almost 12 years ago

(wanted to add my email address)

-- tech

#2

Updated by jrabbit almost 12 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.

#3

Updated by Anonymous almost 12 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.

#4

Updated by jrabbit almost 12 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.

#5

Updated by Anonymous almost 12 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!

#6

Updated by darix almost 12 years ago

  • Status changed from New to Fixed
  • Resolution set to invalid
#7

Updated by stbuehler almost 11 years ago

  • Status changed from Fixed to Invalid

Also available in: Atom