a month ago
Hi Railway team,
We run a headless Chromium browser inside one staging service (Docker builder, node:22-bookworm-slim). Chromium exits immediately at startup:
FATAL:sandbox/linux/services/credentials.cc:137] Check failed: . : Permission denied (13)
TargetCloseError: Protocol error (Target.setDiscoverTargets): Target closed
This is not a credentials, DNS, or application error — the failure occurs inside Chromium's Linux sandbox while it performs the namespace/credential operation used to isolate the renderer process.
Our container is already configured the recommended way:
- Chromium runs as an unprivileged non-root user (titan, via setpriv --reuid=titan --regid=titan). The process never runs privileged.
- Debian's chromium and chromium-sandbox packages are installed, and Chromium's setuid helper is preserved: /usr/lib/chromium/chrome-sandbox, root-owned, mode 4755.
- The executable and helper both exist and pass our file-mode probe at runtime.
We cannot use --no-sandbox. This browser loads untrusted third-party pages, so the sandbox is a required security boundary, not a convenience. (We do use --no-sandbox in a separate code path that renders only our own first-party HTML to PDF — that is not applicable here.)
What we believe is needed: a container runtime/security profile for this service that permits Chromium's sandbox operations — specifically the clone, setns and unshare syscalls used for unprivileged user namespaces. This matches Playwright's documented Docker guidance (non-root browser user plus a seccomp profile allowing user-namespace cloning) and Chromium's Linux sandboxing design. These are container-runtime permissions we cannot grant from our own Dockerfile.
Questions:
- Can Railway provide a sandbox-compatible runtime or security profile for a single service, so Chromium's user-namespace sandbox can initialise?
- If not available today, is there a supported alternative for running a genuinely sandboxed browser on Railway that does not require disabling the sandbox?
This request is scoped to our staging API service only — no production change is being requested.
References:
- https://chromium.googlesource.com/chromium/src/+/0e94f26e8/docs/linux_sandboxing.md
- https://playwright.dev/docs/docker
Thanks,
Keanu
1 Replies
a month ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 1 month ago
a month ago
Hi Keanu, I think your diagnosis is right. Railway still does not expose custom security_opt/seccomp settings for normal services, while Playwright’s sandboxed Docker setup needs clone, setns and unshare to be allowed.
Since you already have chromium-sandbox installed try: chromium --headless=new --disable-namespace-sandbox --dump-dom about:blank
Do not use --no-sandbox.
Chromium’s current code falls back to the SUID sandbox when the namespace sandbox is disabled and the helper is available.
If that fails too, I do not see a Dockerfile fix. Railway would have to allow the sandbox operations at the container runtime level.
One thing I would change in the diagnosis of credentials.cc:137 does not tell us that clone, setns or unshare was the syscall that failed. It tells us Chromium hit a permission error while setting up the sandbox. unshare -Ur true would at least confirm whether user namespaces are blocked.