You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(agent): the allowlist covers the whole line, and coder test stops being the way around it (#1531)
Strict mode checked the first word of a command and nothing else. A line is
a sequence of invocations, so that made any allowed command a passphrase
for the rest of it: ls followed by an ampersand pair carried an arbitrary
command straight past the gate. "Only commands from the allowlist can be
executed" was not true of any line with an operator in it. Every segment is
held to the same rule now, decomposed by the shell parser that was already
in the tree, so a quoted operator stays a quoted operator and is not
mistaken for a chain.
Two things kept that from becoming a regression. A line the parser cannot
read falls back to the previous single-command check rather than failing
closed, because a host whose shell is not bash would otherwise lose every
command. And the navigation builtins joined the list: cd, pwd, pushd and
their neighbours carry no capability of their own, and refusing them once
every segment is checked would have broken a directory change followed by a
build while withholding nothing.
Nineteen commands the documentation lists as allowed were not on the list
at all, so strict mode refused npx, base64, openssl, poetry, zig, istioctl
and the rest while the page said otherwise. They are on it now.
Two settings did nothing when written the way they were documented. The
custom allowlist split on commas while the documented example used
semicolons, which registered one command with semicolons in its name; extra
read paths split on the native separator while the documented example used
semicolons, which produced one path that exists nowhere. Both accept either
spelling now, except that a colon is still never a separator on Windows,
where it separates a drive letter from its path.
The coder test subcommand takes an arbitrary command and ran it through
none of the guards its sibling applies: not the dangerous-pattern check,
not the sandbox, and not the upstream gate, which only ever looked at exec.
The same payload the exec path refuses executed through test. It is guarded
now, with the same escape hatches, so a suite that legitimately needs them
is not newly refused, and the upstream gate covers both subcommands rather
than the one that happens to be named after running commands.
Co-authored-by: diillson <diiilllson@gmail.com>
0 commit comments