Turns out, that was a terrible idea.
Putting privilegedactions in actions/ meant that we tried to interpret
it during startup (along with other similarly silly bugs). The
fastest way to fix this issue is to merely revert it.
I'm sure there are still some exploits in the code, but there are
certainly fewer now. Instead of just executing whatever arguments are
passed into privilegedactions.privilegedaction_run, we now limit the
actions that can be run in the following ways:
- Only actions that exist in the actions directory can be executed.
Attempting to run the action "echo; rm -rf /" will look for a file
named "actions/echo; rm -rf /", of which there are none.
- Shell literals are escaped: attempting to run the "echo" action with
options like "'hi'; rm -rf /") will echo "'hi'; rm -rf /".
- It is difficult to interact with the spawned process through this
interface. We can't control whether the spawned process allows
interaction.
The details of the contract are included in privilegedactions.py, and
this contract is tested in privilegedactions_test.py.
