feat(cli): --allow-path / --allow-read-path for per-session filesystem grants#100
Merged
Conversation
…m grants Add two repeatable flags that grant filesystem access to an extra directory or file for a single session, without authoring a profile: --allow-path read+write (appended to AllowRead + AllowWrite) --allow-read-path read-only (appended to AllowRead only) Both accept a directory or a file and reuse the existing per-session AllowRead/AllowWrite plumbing, so they work on Linux (bubblewrap + Landlock) and macOS (Seatbelt) with no sandbox-layer changes. Grants are applied after profile merge and watch overrides, and nothing is persisted. Non-existent paths are tolerated, matching --allow. Tests: unit test for the flag-merge helper, macOS Seatbelt rule test (rw vs read-only, incl. a file case), Linux bind-mount test, and smoke tests covering write-allowed, read-only (write denied), and a negative control.
…-opt-0qr # Conflicts: # cmd/greywall/main_test.go
The Linux test asserted buildDenyByDefaultMounts emits a writable --bind for --allow-path, but that function only does read-only binds; the writable --bind for AllowWrite lives in WrapCommandLinuxWithOptions. Extract that inline logic into writableBindArgs so the test can verify both layers (read --ro-bind for all grants, writable --bind only for --allow-path). Also fix gosec G301 by tightening test dir perms to 0o750.
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.
Summary
Greywall is deny-by-default for the filesystem: a sandboxed command can only touch the current working directory (plus system paths). Granting one extra directory or file previously required authoring a profile. These two repeatable flags grant that access for a single session, with nothing persisted to disk:
--allow-path <path>— grants read+write (appended toAllowRead+AllowWrite)--allow-read-path <path>— grants read-only (appended toAllowReadonly)Since the sandbox is deny-by-default, no
--deny-*flags are needed.Why
A common need is a scratch/temp dir, a sibling project, or a reference dataset for one run — without the ceremony of writing and maintaining a profile. These flags cover that case ergonomically.
How it works
Both flags accept either a directory or a file, and reuse the existing per-session
AllowRead/AllowWriteplumbing, so they work on Linux (bubblewrap + Landlock) and macOS (Seatbelt) with no sandbox-layer changes. Paths may be absolute, relative (resolved against CWD), or~-prefixed. Grants are applied after profile merge and watch overrides so they always take effect; non-existent paths are tolerated, matching--allow.Validation
applySessionAllowPaths)--bind(rw) vs--ro-bind(ro), including a file~/non-existent/empty paths, repeatable + mixed flags, and confirmed an explicit profiledenyWritestill wins over--allow-pathChecklist
make fmt && make lintcleanmake testpassingdocs/cli-reference.md)