e2e: the container limits an operator wrote are the ones docker is given - #265
Merged
Conversation
… is given The container flags had no coverage. The suite's one docker case proves a container runs and skips itself without a daemon, so nothing checked that --memory, --cpus, --network, --container-user or --container-workdir survive the trip to the command line. They fail quietly: a dropped memory cap behaves like a cap until the day it does not, and a dropped `--network none` is a downstream with the network it was denied. The fixture needs no Docker. DockerBinary searches PATH before its well-known locations, so a recording stand-in earlier on PATH is what runs — and it records the real argv the spawner built rather than a second rendering of the same config. Assertions are flag/value pairs, not substrings: "--memory" appearing somewhere says nothing about what it was set to. The second case is the security half. A container's command line is readable in ps(1), so passing -e KEY=value would put every configured API key there for any process on the machine, including the ones a contained downstream exists to be protected from. The spawner passes -e KEY alone and routes the value through the CLI's own environment, so the assertion is that the VALUE is absent everywhere in the argv — the flag being present only establishes the variable was not dropped. The third pins where --docker-arg lands, which is the whole of its contract: before the image it configures the container, after it configures the contained program. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The container flags —
--memory,--cpus,--network,--container-user,--container-workdir,--docker-arg— had no end-to-end coverage at all. Theone docker case in the suite proves a container runs, and skips itself
wherever no Docker daemon does; nothing checked that the limits an operator
wrote are the limits the container gets.
They fail in the direction that does not announce itself. A dropped
--memoryis a container with no cap, which behaves exactly like one with acap until the day it does not; a dropped
--network noneis a downstream withthe network it was specifically denied.
These need no Docker.
transport.DockerBinarysearches PATH before itswell-known locations, so a recording stand-in placed earlier on PATH is what
the gateway executes — and what it records is the real command line the
spawner built, not a second rendering written for a test.
--docker-arglands