alt Hacker NewsI wonder how he imagines you can give shell access but securely prevent arbitrary command execution.
His complaint that "echo git | bash" still works is particularly nutty.
Replies
This is very doable - it's a shell you're creating within the cli so you have a lot of control over the environment. If you look at tools like sandbox-exec & apparmor, they specifically target binaries, not string input. E.g. if I write a bash script & put it in my path, OpenCode's allowlists aren't looking at the commands my bash script is exec-ing, nor monitoring subshells it creates. A proper sandbox has full context of the execution chain. Not only that, it's potentially much more powerful & expressive in that you can allowlist indirect filesystem access from commands run.
For example, I recently ran opencode via sandbox-exec & naively granted the sandbox access to the aws cli. First attempt to exec it failed because I hadn't granted the sandbox access to the credential file in ~/.aws. This took 2 seconds to resolve but effectively highlights how utterly useless the tree-sitter string-parsing they're doing is. It's so concerning because implementing tree-sitter for that is non-trivial to the point that any competent dev should surely realise quickly while implementing it that this avenue is utterly useless. Yet every high-profile agent cli has taken this approach.
Sure, the two main approaches are revoking execute permission from the executable itself, and write-protecting the things that it would modify (like $PWD/.git). Both of these are achievable with sandbox-exec or landlock_restrict_self(2).
This works for the `bash` example too. Spawning a new shell and running arbitrary commands is not an escalation because the child shell inherits the parent's restrictions.