Gateway container runs its internet-facing server as root #1792

Activity

1. joshunrau

   added

   BugType: existing behavior is wrongType: existing behavior is wrong

   Priority: MediumReal value; schedule normallyReal value; schedule normally

   Difficulty: MediumStraightforward change, about a day or lessStraightforward change, about a day or less

   Area: InfrastructureDeployment, Docker, CI, logging, CLIs, build and test toolingDeployment, Docker, CI, logging, CLIs, build and test tooling

   SecurityAuthentication, authorization, data exposure or a vulnerable dependencyAuthentication, authorization, data exposure or a vulnerable dependency

   on Oct 7, 2026
2. joshunrau commented on Oct 26, 2026

   

   joshunrau

   on Oct 26, 2026

   CollaboratorAuthor

   More actions

   Still reproduces on main (d86740e). No open PR touches apps/gateway/Dockerfile, apps/gateway/scripts/run.sh or docker-compose.yaml.

   Correction: the bind mount came later

   7c40422 (2024-02-29) predates ./sqlite. At that point the database was baked into the image (COPY --from=installer /app/gateway.db /app/gateway.db). Both the file and /app were owned by root, so node could neither write the file nor create a journal next to it. The bind mount, run.sh and the template copy came in 5c7a9f5 (2024-12-06), after the image already ran as root. So on every existing deployment, ./sqlite/gateway.db was created by the root run.sh with cp and is owned by root. The fix has to hand that file to node, not only the directory.

   Recommendation: drop privileges in run.sh

   Take the setpriv option, not USER node plus a compose init service. The fix then lives in the image and covers every way the image is run. With the compose option, an admin who runs docker compose pull without git pull (compose tags ${RELEASE_CHANNEL}, which is latest in .env.template) gets a USER node image under a compose file with no init service. The gateway boots, passes /api/healthcheck and answers the API's GET /api/assignments poll from the root-owned file. It fails only on the first write (api.router.ts:50). The mongo entrypoint in the same stack works this way: it chowns /data/db as root, then re-execs through gosu. With this route, the rustfs-init service in #1752 does not need to cover ./sqlite.

   Insert this between the variable assignments and the template copy (run.sh:5-10):

   DATABASE_DIR=$(dirname "$DATABASE_FILE")
   
   if [ "$(id -u)" = '0' ]; then
     mkdir -p "$DATABASE_DIR"
     find "$DATABASE_DIR" \! -user node -exec chown node:node '{}' +
     exec setpriv --reuid=node --regid=node --init-groups --no-new-privs "$0" "$@"
   fi

   • After the re-exec, cp runs as node, so a fresh copy is owned by node.
   • The database directory is the only path the server writes. Cap.js runs with noFSState: true (cap.ts:4), and the production server only reads dist/, so /app/dist stays root-owned.
   • When the script starts as non-root (docker run --user, a Kubernetes runAsUser), check that the directory and any existing file are writable. If not, exit with a message naming the path and the uid. Otherwise a root-owned file again fails only on the first write.
   • Do not add --reset-env. It clears every variable except TERM, including GATEWAY_API_KEY and GATEWAY_DATABASE_URL, and set -u then aborts the re-exec'd script.
   • setpriv is in util-linux, which is Essential in Debian, so it is still there after the move to node:24-slim in API and gateway runtime images ship the full Node build image with gcc, git and turbo, tripling their size #1794. No new dependency.
   • Record in apps/gateway/AGENTS.md that the image starts as root on purpose and drops privileges in run.sh.

   Verification

   After this fix, both checks in the issue still print root. docker compose exec runs as the image's user, and Config.User stays "". Check PID 1 instead: docker compose exec gateway grep ^Uid /proc/1/status should print 1000. Besides a fresh start with no ./sqlite, cover:

   • a ./sqlite/gateway.db created by the current image (the upgrade path);
   • docker run --user 1000:1000 with a writable mount;
   • docker run --user 1000:1000 with a root-owned mount, which should exit with the message.

   The root test rule exempts only scripts/, and #1752 and #1794 have the same gap. Record one exception for image-only changes in .agents/docs/architecture/testing-strategy.md instead of arguing it in each PR.

   Same pattern elsewhere

   caddy:2.7-alpine sets no USER, so the caddy proxy and the web and playground images also run as root. playground is published directly on PLAYGROUND_PORT (docker-compose.yaml:163). web cannot just add USER, because its CMD rewrites /srv/index.html with import-meta-env at startup (apps/web/Dockerfile:30). That belongs in a separate issue.

   _{Triage note written with Claude Code. Code references point at main @ d86740e.}