fix: distinguish runArgs flags from object members in non-devcontainer files - #93
Merged
Merged
Conversation
A "runArgs" that is an object rather than an argv is still walked as
the object it is, so a member named like a flag produced the same path
segments as a flag occurrence and matched a rule's "/runArgs/--flag"
pattern with no flag behind it. Every such rule then took its
non-"runArgs" branch and reported a finding against a property the
document does not have, e.g. `{"runArgs": {"--privileged": true}}` as
`"privileged" is set to true` — in a devcontainer-feature.json too,
where "runArgs" is read as an ordinary array.
Compile a pattern addressing a flag occurrence as such and match it
only against a node the argv traversal produced.
Document the flag addressing in CONTRIBUTING.md, where the
rule-authoring walkthrough did not mention it and the "docker run" flag
table section still said rules ask dockerargs for a flag's values
instead of matching entries themselves.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01USZT4TA9NjYxH5KiFrprXY
…unArgs" The flag-pattern guard alone left "/runArgs/*" reading a "runArgs" that is not an argv: a rule subscribing to it saw an object's members as if they were entries, which is the same misreading, one path over. Descend a devcontainer.json's "runArgs" only as the argv it becomes, so every path under it — the wildcard included — arrives with Node.Arg set. The value is still visited as a whole at "/runArgs". The guard stays for a Feature and a Template, where "runArgs" is not a property at all and is walked as the ordinary data it is, so a member of it can be named like a flag without being one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01USZT4TA9NjYxH5KiFrprXY
nozaq
changed the title
The engine had been made to keep a flag-spelled pattern from matching anything but a flag occurrence, which gave the "--" spelling a reserved meaning under "/runArgs" in the pointer language: a Feature or a Template has no "runArgs" property, so a member of one named like a flag is an ordinary member and matching it is the plain reading of the path. Restore that reading and put the guard where the ambiguity is actually resolved. A rule reporting both a property and a flag cannot tell the two apart by Node.Arg alone, since it is nil for the property and for such a member alike, so the rules reporting one now ask underRunArgs which they were handed. no-docker-socket-mount needs no guard: it declares only Devcontainer, whose "/runArgs" the traversal descends as the argv or not at all. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01USZT4TA9NjYxH5KiFrprXY
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
2 participants
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.
Summary
This change fixes a bug where rules matching
runArgsflags (like/runArgs/--volume) would incorrectly match object members with the same name in Feature and Template files, whererunArgsis ordinary data rather than a command-line argument array.Key Changes
Added flag pattern detection: Introduced
isFlagPattern()function to identify patterns that specifically addressdocker runflags (e.g.,/runArgs/--volume), and added aflagfield to thepatternstruct to track this.Refined runArgs traversal logic: Moved the
runArgsarray check earlier in thevalue()method and added a guard indispatch()to skip flag patterns whennode.Argis nil (indicating the node wasn't produced by flag parsing).Updated documentation: Enhanced comments in
CONTRIBUTING.mdandrule.goto clarify that flag patterns only match in devcontainer.json files and thatrunArgsobjects are traversed as ordinary data.Expanded test coverage: Added test cases across multiple rule tests to verify that
runArgsobject members named like flags (e.g.,{"runArgs": {"--privileged": true}}) are not incorrectly flagged as security issues in any file type.Implementation Details
The fix leverages the existing
node.Argfield, which is only set when a node is produced by flag parsing inrunArgsFlags(). Flag patterns now skip any node wherenode.Argis nil, ensuring they only match actual command-line flags in devcontainer.json files. This allowsrunArgsto be safely used as an object in Features and Templates without triggering false positives.https://claude.ai/code/session_01USZT4TA9NjYxH5KiFrprXY