…878) * fix(security): non-root USER directives for production images (#874) Closes the CSO MEDIUM defense-in-depth gap flagged persistent since 2026-04-05: backend, scheduler, MCP server, and the production frontend ran their CMD as root. An RCE in any of them inherited root, and on the backend that meant the Docker socket bind mount turned a single RCE into fleet-wide reconnaissance. Changes: - docker/backend/Dockerfile, docker/scheduler/Dockerfile: new `trinity` user at UID 1000 (matched UID required — both share /data/trinity.db). - src/mcp-server/Dockerfile: switch to the built-in `node` user (UID 1000). - docker/frontend/Dockerfile.prod: switch to `nginxinc/nginx-unprivileged` (UID 101, binds 8080). nginx.conf + healthcheck + compose port mapping updated to match. NET_BIND_SERVICE/CHOWN/SETGID/SETUID dropped from the frontend caps (no longer needed once nginx is unprivileged). - docker-compose{,.prod}.yml: backend joins `${DOCKER_GID:-999}` via group_add so UID 1000 retains /var/run/docker.sock access on Linux. Dead NET_BIND_SERVICE removed from backend (binds 8000, doesn't need it). PYTHONDONTWRITEBYTECODE=1 added to dev compose so uvicorn --reload stops failing on __pycache__ writes when host UID != 1000. - scripts/deploy/start.sh: pre-creates the host bind-mount data dir with UID 1000 (the Dockerfile's chown is masked by the bind mount); auto- detects DOCKER_GID on Linux (Debian/Ubuntu=999, RHEL/Fedora=~991, Arch=990) so non-Debian hosts don't silently fail with EACCES on the socket. - .env.example: DOCKER_GID ships blank so start.sh auto-detect kicks in. Compose still falls back to 999 if .env value is missing entirely. - .github/workflows/frontend-e2e.yml: `verify-non-root` step asserts UID 1000 in backend/scheduler/mcp-server and exercises the Docker socket via `docker.from_env().ping()` from inside the backend (the prior `/api/agents` probe was a false positive — `list_all_agents_fast` catches every Docker exception and returns []). `verify-prod-frontend-uid` builds the prod frontend image out-of-band and asserts UID 101. Admin password is generated per-run instead of the previous hardcoded fallback (CSO I-01). - docs/memory/architecture.md: new invariant #17 documenting the rule. - docs/migrations/NON_ROOT_CONTAINERS_2026-05.md: upgrade procedure for existing deployments — Docker only honours the Dockerfile chown on first volume creation, so trinity-data and agent-configs volumes from prior root-running containers need to be re-owned manually. - docs/security-reports/cso-diff-2026-05-17.md: audit report of the branch itself. Verification (CI, fresh prod, upgrade): see the migration doc. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * ci(security): split non-root container guards into dedicated workflow Addresses @vybe review on #878. The verify-non-root and verify-prod-frontend-uid guards added in #874 lived inside frontend-e2e.yml, which is `ui`-label-gated — so backend infrastructure PRs (the exact PRs that can regress the guards) skipped them silently. Moves both steps to .github/workflows/container-security.yml with a path filter on docker/**, docker-compose*.yml, scripts/deploy/start.sh, and src/mcp-server/Dockerfile so the guards execute whenever the underlying surface changes — independent of the e2e workflow's UI gate. frontend-e2e.yml keeps the stack boot for Playwright smoke tests but no longer carries the regression guards. Architecture invariant #17 updated to point at the new workflow. * ci(security): set least-privilege GITHUB_TOKEN on container-security workflow Addresses CodeQL finding flagged on PR #878 (security/code-scanning/173): the new workflow defaulted to the repository-default GITHUB_TOKEN scope, which is broader than the workflow actually uses. Pin top-level `permissions: contents: read` — the minimum needed for actions/checkout. The workflow does no PR commenting, issue updating, or security-events writes, so anything beyond `contents: read` would be unused authority. * ci(security): flip setup_completed before auth probe in container-security The new container-security workflow calls /api/token after backend health is green, but on a fresh DB the first-time setup wizard blocks login (`setup_required`, 403) until `setup_completed=true`. Mirror the "Skip first-time setup wizard" step from frontend-e2e.yml — flip the flag directly via `docker exec trinity-backend python3 ...` so the CI sanity probe can mint a token and hit /api/agents. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Uh oh!

Client/Viewer User Role (AUTH-002) #17

Description

Activity

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions