kevinveenbirkenbachandClaude Opus 5.5 46fe011796 fix(web-app-fusiondirectory): lift the PHP memory_limit in the FPM pool ...

#1259 moved the interim CVE-2026-109618 mitigation (memory_limit = -1)
out of the shared hardening.ini into memory-unlimited.ini and mounted it
only in the roles whose images it had inventoried. Its branch predates
#1263, which gave FusionDirectory the php_hardening mount, so after both
merged FusionDirectory ran with the image default of 128M again.

A conf.d mount would not have fixed it: the nfrastack image writes
php_admin_value[memory_limit] into its FPM pool
(/etc/php7/pools.d/www/www-settings.conf) from PHP_MEMORY_LIMIT, and a
pool php_admin_value outranks every conf.d ini. Measured on main: CLI
128M, FPM 128M. So even before #1259 the hardening ini only ever lifted
the CLI limit.

nfrastack/fusiondirectory:1.5 runs PHP 7.4.33 on Alpine 3.15, end of
life and never patched, so the role carries the mitigation until it
moves to a PHP 8 image.

- Set PHP_MEMORY_LIMIT=-1 in templates/env.j2. The image seds it into
  php.ini and the pool, so CLI and FPM both report -1.
- The root TODO lists FusionDirectory with the image and the reason it
  uses the variable instead of the mount; the role TODO names which
  setting carries which CVE mitigation.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2026-10-30 08:57:44 +01:00

..

compose.yml.j2

…

env.j2

fix(web-app-fusiondirectory): lift the PHP memory_limit in the FPM pool

2026-10-30 08:57:44 +01:00

playwright.env.j2

…