On Thu, May 26, 2011 at 06:13:38PM +0200, Ondřej Surý wrote: > Package: libapache2-mod-php5 > Severity: normal > > Hi Raphael, Sean, > > I am enabling the pcntl in CGI module (since it cannot apparently read > the apache2 memory) in the git.
with libapache2-mod-php5, the php code is dlopen()'d and executed in the memory space of the apache process itself, whereas the cgi script is a seperately executed process. there's still the possibility that the cgi process could execute code that attached to another process and did naughty things in a similar manner, but (a) i don't think it needs pcntl enabled to do so, and (b) the linux kernel prevents children of root-but-dropped-privs from attaching to their parents, which would keep us safe (though only as a side effect). but while the memory dumping issue might be moot, you still have the quesiton of whether you want users to be able to spawn off long-lived daemons that are immune to any other php engine controls (max lifetime, memory, etc), and could probably have more usecases of the nefarious variety rather than the legitimate. The single feature request behind this from what was linked by Clint was a user who wanted to do some "postprocessing". Is it me or is this just a case of the tail wagging the broken-design dog? There are already ways to accomplish that (system daemons, cron jobs, whatever) which does not open this box of worms. Perhaps Clint or someone else could put up a better justification for why we want this in the general case, rather than to fix this one guys' idea of "innovative" application design? > But I was thinking if this poses any security problem for fastcgi or > FPM? Maybe we could enable it for FPM, and at most it will be able to > read some FPM memory, which just could be prevented by creating more > FPM pools with user separation. As I understand it (correct me if I'm wrong), FPM processes don't start off as root and drop privileges, meaning any fpm process could already attach/backtrace any other fpm process in the same pool, with or without the pcntl code. So the memory dumping stuff isn't really an issue here, at least not more than it already is. That leaves us with the basically the same follow-up question as the cgi stuff above, though: do we want to let php code fork/daemonize? I'm not saying we should immediately back this out or anything; we have a while before the next stable release to discuss this and I'm open to the idea that maybe there is some reason we want to allow this. And really, i think you're doing all the heavy lifting with PHP these days Ondrej, so ultimately it's your opinion/decision that will probably matter most :) sean -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org