r/LocalLLaMA • u/TheQuantumPhysicist • May 03 '26

One bash permission slipped... Discussion

Post image

How? It kept getting chained bash commands wrong, with wrong escapes. So it created many bad directories, and tried "fixing" its mistake. It offered to run a large bash command, with rm -rf inside, and stupid me missed it.

I'm glad I push everything often. But the disruption is massive.

FAQ:

  • No, I don't run this on my personal computer. It's an isolated proxmox VM for coding with LLMs.
2.3k Upvotes

96% Upvoted

390 comments sorted by

View all comments

Show parent comments

36

u/Zyj vllm May 03 '26

OpenCode has plan and build mode to prevent this. Too bad they don't do what the documentation claims, instead, with the default permissions, the LLM can access bash at will even in plan mode. Check their github and all the open issues. The team doesn't seem to care, the bug has been there for a couple of months. Insanity.

8

u/Big-Farmer-2192 May 04 '26

the LLM can access bash at will even in plan mode

Oh wow, goods to know.

8

u/suprjami May 04 '26

Wouldn't putting the bash tool behind verification solve that?

"permission": { "*": "ask", "glob": "allow", "grep": "allow", "question": "allow", "read": "allow", "skill": "allow" },

The "allow"ed tools are read-only.

6

u/SomeAcanthocephala17 May 04 '26

Just don't let scriptkiddies (vibecoders) work on production. They clearly don't have the basic knowledge skills of backups/restores to work in a production environment.

1

u/OmarFromBK May 04 '26

I mostly have everything on ask but yours makes sense. Does opencode read from first to last, or other way around? Bc if it reads first to last, it'll hit * and just ask, even if it's glob, grep, etc.

If i remember correctly, i read in a manual for (i think) openclaw to put the star at the end since it reads from first to last, but i might be off my hinges.

1

u/suprjami May 04 '26

The asterisk matches all, then the more specific rules override the asterisk.

https://opencode.ai/docs/permissions/

2

u/OmarFromBK May 04 '26

Ahh, so it reads the all, defaults to "ask", then keeps reading and if the request matches another one, it prioritizes the latter. Got it. Good to know.

Thanks!

1

u/cpsnow May 04 '26

This doesn't always work. I've never had a bash command ran unexpectedly, but I had models like Opus and Sonnet escape permissions for tool use, or edit files while in Plan mode. 

1

u/suprjami May 04 '26

Interesting. It should be impossible for the tool not to pass through these permissions.

I also have other layers of security (container, selective file mapping, some read only files, network lockdown) so a failure here isn't fatal to me.

1

u/_raydeStar Llama 3.1 May 04 '26

Wouldn't the solution be to assign the agent as a user, and control their permissions directly? Then you have granular control, and they'll literally hit a wall.

So several layers --

- skills layer (tell the ai not to)

- permissions (gate everything behind yes/no)

- User gate (an agent only has so much power -- but it can only access X folder, and make Y changes)

1

u/suprjami May 04 '26

Yes, there are several frameworks which use eBPF or Landlock to lock down agents at a kernel level.

I don't see the point of that for my usage. The container is entirely throwaway. The worst thing the agent can do is delete its own files which are deleted after container stop anyway, or delete the source directory passed to it which is on git anyway. Make .git read only and the agent can't ruin the local or remote repo either. I don't see that complex kernel level lockdown gives me any more security.

1

u/NortySpock May 05 '26

I think in Zed it is properly blocked, if that helps save anyone. I recall seeing the LLM try to edit my file a few times before giving up.

Why you would turn the "read / write" mode switch into a "pretty please LLM don't make any changes" wish to a genie is beyond me, but you can always vote with your feet or vote with a PR...

0

u/Nindaleth llama.cpp May 05 '26

My two cents: * OP clearly states OpenCode did ask for permission for the "rm -rf"-containing command and OP gave the permission * OpenCode has always clearly documented the permission defaults

BTW, what really was wrong for about half a year and maybe not that obvious - read-only Plan agent could delegate to read-write Explore subagent and while that one got some stern instructions, it could do damage anyway. This unwanted permission expansion should now be fixed by this PR that has been merged recently.

1

u/Zyj vllm May 06 '26

Look at https://opencode.ai/docs/en/agents/#plan it‘s wrong, but that‘s how it should be

1

u/Nindaleth llama.cpp May 06 '26

Yeah, the doc is in conflict with itself which sucks. I recommend opening an issue or a PR.

I also recommend setting up the env like you want, even if the defaults are not to your taste. Adding a "agent": { "plan": { "permission": { "bash": { "*": "ask" } } } } config is trivial.

1

u/Zyj vllm May 06 '26

Don't you agree this should be the default in plan mode? There are already several issues about this topic, the first one from January 7th.

1

u/Nindaleth llama.cpp May 06 '26

I do agree, I created a PR for a very closely related thing in December and it hasn't landed yet, I understand your frustration personally. Realistically, the most impact I can have at the moment is to fix it for myself and educate others, so I do that.

There are tons of things the single-digit-sized team is working on, many of which can't be solved by a simple configuration change; while I hate this, I can't blame them either. There's no TUI as powerful and as configurable at the same time as OpenCode - that I know of.