This doesn't require cooperation from the shell. If writable paths are non-executable, and executable paths are non-writable, then executing `cp $(which git) my-new-favourite-binary` doesn't grant you permission to run it.

The part which does require cooperation (from outside of the shell, i.e. from the harness) is the ability to upgrade writable paths to executable, at the cost of writability and whatever other restrictions you place on the binaries generated by your agent.

This kind of W^X invariant is widely deployed in every desktop operating system, and the type of W-X upgrade hook I described is used by every JIT engine.

▲

wren6991 21 hours ago | parent | next [-]

Replying inline because this hit max depth:

> You are confusing CPU-level security with filesystem-level security.

> I'm curious - how do you expect an LLM harness to build and test executables without being able to build and execute executables?

W^X applies to file systems as well as page tables, and this is called out in paragraph 4 of the Wikipedia article you didn't read. Respectfully, I'm leaving this conversation at this point because it doesn't seem productive.

	▲	qarl2 21 hours ago \| parent [-]
		You did not hit max depth - you hit a timer designed to prevent rage posting. My question stands - if you accept that LLM harnesses are designed to allow the building and testing of executables - how do you imagine you can prevent the building and running of executables? Respectfully.

▲

qarl2 21 hours ago | parent | prev [-]

You are confusing CPU-level security with filesystem-level security.

I'm curious - how do you expect an LLM harness to build and test executables without being able to build and execute executables?