Summary
Add a host-enforced size cap to sprite file pull so the caller can bound how many bytes land on its disk during a pull, independent of anything the box reports.
Motivation
sprite file pull is atomic and unbounded: the host has no way to cap the number of bytes written locally mid-transfer. When the file being pulled was produced by an untrusted box (e.g. a build box running arbitrary dependency install code), the host must currently either
- (a) trust a box-emitted size count before pulling, or
- (b) let the full file land and check its size afterward.
Both let a hostile box that writes a huge file drive a disk-pressure DoS on the shared host before any host-side check can trip. A box-side stat/wc -c pre-check does not help — it is the same untrusted box reporting the size over a different code path, so a box that under-reports its file size defeats it just as easily as it defeats a trusted header.
Proposal
A transfer-time cap the host enforces, independent of anything the box says:
sprite file pull --max-size <bytes> -s <box> <remote> <local>
- Abort the transfer as soon as the received/written size exceeds
<bytes>.
- Exit non-zero with a distinguishable status/message (e.g.
exceeded max-size), and remove the partial local file, so the caller can treat it as a typed oversize failure.
- The cap is enforced by the transport itself, so a box that under-reports its size cannot bypass it.
A sprite file stat -s <box> <remote> that returns a control-plane-measured size (not a box-shell-measured one) would be an acceptable alternative if a streaming cap is harder to add.
Context
We build on Sprites as an untrusted-code execution tier and move workspace tarballs host↔box via sprite file pull/push (byte-exact, which is great — see the related sprite exec stdout report). The one remaining gap is that the pull can't be size-bounded on the host side without trusting box-emitted counts. Happy to help test a prototype.
Summary
Add a host-enforced size cap to
sprite file pullso the caller can bound how many bytes land on its disk during a pull, independent of anything the box reports.Motivation
sprite file pullis atomic and unbounded: the host has no way to cap the number of bytes written locally mid-transfer. When the file being pulled was produced by an untrusted box (e.g. a build box running arbitrary dependency install code), the host must currently eitherBoth let a hostile box that writes a huge file drive a disk-pressure DoS on the shared host before any host-side check can trip. A box-side
stat/wc -cpre-check does not help — it is the same untrusted box reporting the size over a different code path, so a box that under-reports its file size defeats it just as easily as it defeats a trusted header.Proposal
A transfer-time cap the host enforces, independent of anything the box says:
<bytes>.exceeded max-size), and remove the partial local file, so the caller can treat it as a typed oversize failure.A
sprite file stat -s <box> <remote>that returns a control-plane-measured size (not a box-shell-measured one) would be an acceptable alternative if a streaming cap is harder to add.Context
We build on Sprites as an untrusted-code execution tier and move workspace tarballs host↔box via
sprite file pull/push(byte-exact, which is great — see the relatedsprite execstdout report). The one remaining gap is that the pull can't be size-bounded on the host side without trusting box-emitted counts. Happy to help test a prototype.