v0.1.2 hotfix: add required capabilities for entrypoint init under cap_drop ALL

[bdeetz]

Known Impacted Versions

• bf1e0d3
• v0.1.2

Problem

Test runs with different cap than what's required.

/entrypoint.sh: line 112: /data/.magpie-init.lock: Permission denied

Root Cause

docker-compose.prod.yml specifies cap_drop: ALL for security hardening, which removes all Linux capabilities — including ones essential for the entrypoint's "start as root → init → drop privileges" pattern:

• CAP_DAC_OVERRIDE — needed for root to write to the /data bind mount owned by a non-root host user
• CAP_SETUID / CAP_SETGID — needed by gosu to drop privileges
• CAP_CHOWN — needed to set correct ownership on directories created during init

Fix

docker-compose.prod.yml

Added cap_add with the 4 minimum capabilities needed after cap_drop: ALL:

• CHOWN, DAC_OVERRIDE, SETUID, SETGID

This follows the same pattern already used by the Caddy service in the same file.

entrypoint.sh

Added early creation of the storage directory (/data/artifacts) before the lock file resolution logic. On first boot, the directory doesn't exist yet, causing the lock file to fall back to /data. Creating it early keeps the lock file in the correct location.

Security

These capabilities are only effective during the brief root initialization phase of the entrypoint. After gosu switches to the target UID/GID, they have no effect. The container retains read_only: true, all other capabilities remain dropped, and the application runs with zero capabilities.

Testing

• All 977 unit tests pass
• Ruff lint/format clean
• Shellcheck clean on both shell scripts
• Code review approved

(AI-generated via Claude Code w/ Opus 4.5)

Manual testing

• upon initialization of magpie on a fresh install of ubuntu 24.04, the magpie container failed to start. After building with these changes, the container made it further in the initialization process.