Support for arbitrary power devices via shell commands

[LittleNyanCat]

Allows users to implement support for any device they wish themselves, by running a shell command of their choosing.

Addresses #932.

[Arksine]

Thanks. Unfortunately this can't be merged into mainline, as configurable script execution exposes potential security issues, particularly on installations in public areas like dormitories an labs.

[LittleNyanCat]

In such scenarios your installation should already be protected to not allow anyone to interact with your WebUI/Moonraker's API, if it isn't then that's the user's fault.

Besides, the scripts are fixed, they don't receive arguments from the API, and if you're worried about someone modifying moonraker.conf for arbitrary command execution, I'd argue that you already have way bigger problems if someone managed to get read/write access to your host's filesystem (or just the printer's config files in general).

[Arksine]

In such scenarios your installation should already be protected to not allow anyone to interact with your WebUI/Moonraker's API, if it isn't then that's the user's fault.

Regardless of whose fault it is, my goal is to limit exposure should a malicious actor gain access to the instance of a default installation (no mods). Currently the worst case scenario is an unauthorized individual can control the printer and reconfigure software. Bad, but limited.

Besides, the scripts are fixed, they don't receive arguments from the API, and if you're worried about someone modifying moonraker.conf for arbitrary command execution, I'd argue that you already have way bigger problems if someone managed to get read/write access to your host's filesystem (or just the printer's config files in general).

Moonraker provides r/w access to the gcodes and config directories, so users can modify the configuration. What they cannot do is modify the source code for Moonraker, Klipper, or any software registered with Moonraker, even if for some reason the user symlinked it in one of the writable folders. While it isn't ideal for unauthorized users to be able to reconfigure software, the actions they can currently take do not include running malicious code. Configurable scripts change that, so I would respectfully disagree that a malicious actor gaining access in the current situation is a bigger problem.

I understand why some users would like this functionality, however it isn't something I am comfortable with in mainline Moonraker. There are a few other options:

1. A 3rd party component that configures the "switch" and registers itself with the power component. I don't endorse or provide support for 3rd party modifications to Moonraker, but I have nothing against them either. This could require maintenance if power.py changes.
2. A small http server bound to the localhost that provides endpoints which will run the desired scripts. Moonraker could then be configured with the generic http type. This is probably the easiest method, I would imagine most people with the skills to write a shell script can figure out how to create a simple server in Python.
3. Similar to above, but using an MQTT client that subscribes to topics that will execute the script. This is a step up in difficulty and requires a broker, so not ideal for everyone.
4. Its possible to jumper two GPIOs. One Moonraker writes to, the other is monitored by a script. The primary issue with this method is that the gpio will turn off when Moonraker restarts.