The question to ask is should these defaults be tightened. For example, disallow read and execution of anything outside /var/www/, such as /usr/bin/sh. For example, block syscalls PHP won't ever use to limit chance of a compromised PHP process being able to utilise a LPE kernel vulnerability. And then update user installation documentation to explain the onus is on the user to open up very restrictive default permissions should they really have a need to do so.
The bad practices mentioned in GP have nothing to do with this vulnerability
These bad practices do matter because the fundamental principle of https://en.wikipedia.org/wiki/Defense_in_depth_(computing) which php-fpm (bundled with PHP) attempts to use through some fairly open sandboxing[1] defaults within https://raw.githubusercontent.com/php/php-src/refs/heads/mas...
The question to ask is should these defaults be tightened. For example, disallow read and execution of anything outside /var/www/, such as /usr/bin/sh. For example, block syscalls PHP won't ever use to limit chance of a compromised PHP process being able to utilise a LPE kernel vulnerability. And then update user installation documentation to explain the onus is on the user to open up very restrictive default permissions should they really have a need to do so.
[1] https://www.freedesktop.org/software/systemd/man/latest/syst...