supervisord runs as root inside the container but cap_drop: ALL still
blocked it from signaling opendkim (a different uid) — cross-uid
kill() checks CAP_KILL regardless of the caller's uid. Domain add was
failing in prod with "unknown problem sending sig opendkim ...
PermissionError: Operation not permitted".
Bringing up the production Apache stack for real surfaced a latent bug
in the Phase 10 hardening: cap_drop: ALL with only NET_BIND_SERVICE/
CHOWN/SETUID/SETGID/DAC_OVERRIDE left the root startup phase unable to
chmod the /data dirs it had just chowned to the panel user (needs
CAP_FOWNER) or set their setgid bit (needs CAP_FSETID). The container
crash-looped on "chmod: Operation not permitted". Phase 10 never caught
this because its compose up hit a port conflict before full boot.
Add FOWNER and FSETID to cap_add and document what each capability is
for. Verified: container now starts clean under the hardened compose.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- deploy/docker-compose.yml: pinned-tag ghcr image, hardened (cap_drop ALL +
minimal cap_add, no-new-privileges, panel bound to 127.0.0.1 only). Apache
itself runs on the host (spec 10.5), fragment at deploy/apache/.
- Alternative reverse-proxy fragments: nginx (+certbot sidecar), Caddy
(automatic ACME), Traefik (+acme.json PEM extraction script).
- .github/workflows/release.yml: tag-triggered ghcr.io publish, version piped
from the git tag into both the binary ldflags and the image tag (spec 10.1).
- Closed a gap from Phase 1: logrotate was installed but never invoked;
wired up build/logrotate-mail.conf + logrotate-loop.sh + a supervisor
program (copytruncate, since postlogd holds mail.log open with nothing to
signal on rotation).
- README rewritten: site requirements checklist, reverse-proxy comparison,
DNS setup (server- vs domain-level), IP warmup, backup/restore vs domain
export/import, fixed-tag rationale, machine requirements.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
mix