[Groxx]

>Any shell commands were executed without triggering human approval as long as:

>(1) the unsafe commands were within a process substitution <() expression

>(2) the full command started with a ‘safe’ command (details below)

if you spend any time at all thinking about how to secure shell commands, how on earth do you not take into account the various ways of creating sub-processes?

[1718627440]

Also policing by parsing shell code seems fundamentally flawed and error prune. You want the restrictions at the OS level, that way it is completely irrelevant how you invoke the syscalls.

[Groxx]

You can likely get away with it by being very strict and only doing it for a handful of "safe" things, e.g. `cat` has no way (that I know of) to do arbitrary code execution by feeding it a filename.

So if you allow exclusively single-quoted strings as arguments, `cat` should be fine. Double quoted ones might contain env vars or process substitution, so they would need to either be blocked or checked a heck of a lot more smartly, and extremely obviously you would have to do more to check process substitution outside strings too. But a sufficiently smart check could probably allow `cat <(cat <(echo 'asdf'))` without approval... unless there's something dubious possible with display formatting / escape codes, beyond simply hiding things from display.

I would not at all consider this to be "a sandbox" though.

And obviously that doesn't work for all, e.g. `find` can run arbitrary code via `-exec`, or `sh` for an extreme example. But you can get a lot done with the safe ones too.