php:*-apache + cap-drop ALL: mod_unixd setgid() failure leaves Apache workers running as UID 0 (privilege separation silently broken) #1707

Summary

On the php:8.4.26-apache image (also reproduced with a locally built variant), running the
container with all capabilities dropped while the Apache parent starts as root breaks Apache's
privilege separation silently from a security perspective: mod_unixd cannot setgid()
(no CAP_SETGID), logs an alert, but the worker still serves requests as UID 0 instead of
www-data.

This matters because "root parent + --cap-drop ALL" is a common hardening recipe, and the
result is the opposite of the intended outcome: a compromised worker (any RCE in a PHP app)
executes as UID 0 rather than www-data.

Reproduction

docker run -d --name t --read-only --cap-drop ALL \
  --tmpfs /var/run/apache2 \
  -p 127.0.0.1:8080:80 php:8.4.26-apache
sleep 3
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/   # 200 — service looks healthy
docker top t -o user,pid,ppid,args
docker logs t 2>&1 | grep AH02156

Observed:

$ docker top t -o user,pid,ppid,args
USER   PID    PPID   COMMAND
root   1692   1669   /usr/sbin/apache2 -DFOREGROUND
root   3261   1692   /usr/sbin/apache2 -DFOREGROUND      <- worker, UID 0

$ docker logs t | grep -m1 AH02156
[unixd:alert] [pid 36] (1)Operation not permitted: AH02156: setgid: unable to set group id to Group 33

/proc/<worker>/status confirms Uid: 0 0 0 0 (with CapEff: 0 — so this is not full
root capability-wise, but it still owns every root-owned file on the filesystem for DAC
purposes, e.g. it can read /etc/shadow via owner bits, which www-data cannot).

The alert appears once per forked worker; HTTP keeps serving 200s, so nothing in normal
operation tells the operator that privilege separation is gone.

For contrast, starting the same image properly as non-root
(--user 33:33, unprivileged port, tmpfs /var/run/apache2 owned by 33) works fine and
workers run as www-data as expected — no AH02156.

Context

We hit this while testing exploit containment for the recent PHP vulnerabilities
(CVE-2026-109618 / CVE-2026-109619, "php2shell") under hardened-container recipes. Full
write-up of the matched-pair experiment:
https://github.com/srayuth089 (lab notes) — happy to attach raw logs if useful.

Questions

1. Is this behavior known / already being worked on (I couldn't find an existing issue)?
2. In the team's view, does this warrant a fix in the image (e.g. fail loudly at startup if
   the parent is root but CAP_SETGID/CAP_SETUID are missing), or is it best handled as
   documentation (a short "non-root usage" section in the image README describing the
   supported pattern)?
3. If documentation is the preferred route, we're happy to send a PR with the verified
   non-root recipe (user 33, port >1024, /etc/apache2/envvars, tmpfs ownership) — would
   that be welcome in docker-library/docs, here, or both?

Not claiming this is a CVE by itself — it's a hardening-guidance foot-gun that inverts the
user's security intent, discovered during authorized lab research.