From 79b8c582340397af421d1147b4cb9dec4dbe2f7f Mon Sep 17 00:00:00 2001 From: orveth Date: Fri, 21 Aug 2026 07:39:15 -0700 Subject: [PATCH] docs(sandbox): correct two false mechanisms in the cursor comment MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The install-script paragraph explained itself with a user that does not exist. It said /root/.local is unreadable by "the `agent` user this image runs as"; there is no `agent` user, the image creates none, and it sets no USER at all — so a bare `docker run` is root. The decision to take the tarball is unchanged and the real mechanism is worse. Jobs arrive as a host uid through `docker run --user`, which this file already documents 100 lines below. So a /root/.local install is readable by a bare `docker run` and unreadable by every real job: it passes exactly the test someone would think to run, and fails only when a buyer's sats are on it. `cursor-agent` is also not the program. It is 1,074 B of bash that execs the package's own bundled node (dist-package/node, ~129 MB), so this image's /usr/local/bin/node does not run cursor. That strengthens the reason for digesting the tarball — the digest has to cover the interpreter, not just the .js beside it — and it moves the open gVisor question onto a different binary, alongside the `cursorsandbox` and `crepectl` helpers the package ships. Comment-only, and proven rather than asserted: strip every comment and blank line from this file at main and at this head and the two are byte-identical. Zero instruction lines differ. Co-Authored-By: Claude Opus 5 (1M context) --- docker/maxplayer-sandbox/Dockerfile | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/docker/maxplayer-sandbox/Dockerfile b/docker/maxplayer-sandbox/Dockerfile index 8790aa5f8..c27f9da5c 100644 --- a/docker/maxplayer-sandbox/Dockerfile +++ b/docker/maxplayer-sandbox/Dockerfile @@ -62,11 +62,18 @@ RUN npm install -g \ # measured reasons: # * The script HARDCODES its own version, so fetching the script is unpinnable while fetching the # tarball is pinnable — which keeps the reproducibility property the paragraph above establishes. -# * The script derives every path from $HOME and exposes no override. Run as root in a build that -# is /root/.local, which the `agent` user this image runs as cannot read: a green build and an -# unusable cursor. -# The tarball is also the right unit to digest. A digest over `cursor-agent` itself would cover a -# 4 KB launcher script, not the bundled Node application it execs. +# * The script derives every path from $HOME and exposes no override, so a build — which runs as +# root — installs under /root/.local. A job cannot read that: jobs arrive as a host uid via +# `docker run --user` (see the HOME note further down), and only root can read /root. The trap +# is that it would look fine in testing, because this image sets no USER and a bare `docker run` +# is therefore root and CAN read it. It would fail only on real jobs, which is the worst +# available shape for a green build. +# The tarball is also the right unit to digest, because `cursor-agent` is not the program. It is a +# 1,074 B bash script that execs the package's OWN bundled node (`dist-package/node`, ~129 MB) — +# this image's /usr/local/bin/node does not run cursor. A digest over the launcher would leave both +# that interpreter and every .js beside it free to move under a passing check. The package also +# ships `cursorsandbox` and `crepectl`, so what has to survive gVisor is the vendor's node and those +# helpers, never the node measured on runsc elsewhere. # # `node` does the fetch and the hash because it is already here (it is this image's Cmd) and `curl` # is not — so this adds no package to an image that runs a stranger's code.