fix(permissions): enforce deny rules over the allow list (fixes #313)#314
Open
glitch-ux wants to merge 1 commit into
Open
fix(permissions): enforce deny rules over the allow list (fixes #313)#314glitch-ux wants to merge 1 commit into
glitch-ux wants to merge 1 commit into
Conversation
allowed_tools short-circuited evaluate() before the path deny-rules and denied_commands checks, so allow-listing a broad tool (e.g. bash or write_file) silently bypassed the user's own deny policy -- a configured denied_commands pattern or path deny-rule provided no protection once the tool was allow-listed. Move the path deny-rule and denied_commands checks ahead of the allowed_tools short-circuit so deny takes precedence over allow, consistent with denied_tools and the built-in sensitive-path patterns (which are already evaluated before the allow list). Add regression tests covering both deny paths plus a control that the allow list still grants a tool when no deny rule matches. Fixes HKUDS#313
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
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
Problem:
PermissionChecker.evaluate()returned allow for any tool inallowed_toolsbefore it evaluated the user-configuredpath_rulesdeny-rules anddenied_commandspatterns. Allow-listing a broad tool such asbashorwrite_filetherefore silently disabled the user's own deny policy — a configureddenied_commands: ["*rm -rf /*"]or a/etc/*path deny-rule provided no protection once the tool was allow-listed. This is inconsistent with the rest of the checker, where deny already wins:denied_toolsand the built-in sensitive-path patterns are both evaluated before the allow-list (andtest_allowed_tools_does_not_bypass_sensitive_pathsasserts exactly that for sensitive paths).Change: Move the path deny-rule check and the
denied_commandscheck ahead of theallowed_toolsshort-circuit inevaluate(), so deny consistently takes precedence over allow. Behavior is otherwise unchanged: an allow-listed tool still runs when no deny rule matches.Added regression tests covering both deny paths and a control asserting the allow-list still grants a tool when no deny rule applies.
Fixes #313.
Before / after
Validation
uv run ruff check src tests scripts— passesuv run pytest -q tests/test_permissions— 35 passed (3 new)uv run pytest -q— full suite passes except two pre-existing failures unrelated to this change (test_bundled_user_invocable_skill_registers_as_slash_command,test_load_skill_registry_includes_bundled); both fail identically on a cleanmain.cd frontend/terminal && npx tsc --noEmit— not applicable (no frontend changes)Notes
allow=Trueremain advisory (no behavior change), matching current semantics.