Charles Morris wrote: > I agree with you that this is a known issue, and that there are ways > around it, however I would in fact call it a vulnerability. That depends upon your threat model. If you are treating max_execution_time as protection against malicious scripts, then it's a vulnerability, and not one which is easily fixed. OTOH, if you merely consider it a precaution against "runaway" scripts, which aren't actively trying to evade such constraints, then it's just a limitation (and, AFAICT, an intentional one, i.e. it's only intended to limit CPU usage). > I am of the opinion that PHP ... should automatically interrupt any > processes in the process tree from the current script execution That's easier said than done, particularly if you are trying to protect against malicious scripts. A child which is trying to evade such termination can fork() and have the parent exit. This will leave a gap in the chain of parent/child relationships, so it can no longer be traced back to the original child process. Even if PHP runs each child in a separate process group or session, the child can just move itself to a new process group or session. Almost anything which is inherited across a fork() can be discarded or changed. The things which can't (UID, GIDs, chroot, etc) would need root privilege to initialise. Essentially, once PHP has spawned a child, it's control over the child and its descendents is limited to whatever features the kernel provides. If you limit yourself to bare-bones POSIX (no capabilities, or extensions such as SELinux or RSBAC), the set of features is rather lacking in this regard. -- Glynn Clements <glynn@xxxxxxxxxxxxxxxxxx>
