4 hours ago
Please confirm the supported container sandbox policy for our existing
PCAI-Staging → staging → pcai-mvp service. This is an instructions-only request;
do not deploy, change settings or permissions, create resources or incur charges.
We have now reproduced and corrected the native browser failure in an isolated
non-root container. The exact browser launches securely and passes JavaScript,
large-page, access-control, resource and cleanup tests at 0.5 vCPU and 500 MB.
It runs as UID 1000 with all container capabilities dropped, no-new-privileges,
read-only root and Chromium's native sandbox enabled. No SYS_ADMIN, privileged
mode, unconfined seccomp or sandbox-disable flags are used.
The host must allow the namespace sandbox syscalls clone/setns/unshare and the
chroot syscall Chromium uses to restrict its filesystem within its own user
namespace. Default-deny filtering remains enabled. A seccomp profile that
conditionally denies chroot when CAP_SYS_CHROOT is absent caused a native trap;
allowing that syscall without granting any host capability resolved it.
Can the existing Railway service support this configuration, either through its
current runtime policy or a supported custom policy? If yes, provide the exact
supported configuration instructions. If not, please state the restriction so
we can place only the isolated renderer in a compatible execution environment.
No account secrets, customer records or database access are needed.
We will not start another deployment until runtime compatibility is established.
The current public-website cutover preparation is independent of this renderer.
1 Replies
4 hours ago
For a normal service deployment, our runtime does not apply a syscall filter that blocks clone, unshare, setns, or chroot for a non-root process, so a UID 1000 Chromium with its native sandbox enabled is not restricted at that level and needs no extra capability, privileged mode, or sandbox-disable flag. There is no service setting or API option for a custom seccomp profile, capability adds/drops, no-new-privileges, privileged mode, or a read-only root filesystem, so the configuration you described is applied by your image itself (running as UID 1000), not by a Railway setting.
One thing we can't certify from the policy alone is unprivileged user namespace creation inside the guest kernel, which Chromium's namespace sandbox also relies on; the browser's own startup output on the service will show whether the sandbox initialised.
Status changed to Awaiting User Response Railway • about 4 hours ago