CLI improvements

[walid-git]

[walid-git]

• Added a callback in struct cli_cmd_desc that allows sensitive commands to provide their own logging function. If a sensitive command does not provide an implementation, then only the command name followed by (hidden) will be logged (no arguments). The command response is also logged as (hidden).
• Added coverage for internal and sensitive commands by introducing debug commands with the respective flags.
• Unknown commands are no longer forwarded to the child, this will prevent command smuggling using quotes.
• Also, fixed a bug introduced by cd2cfbd522f7dd2dd143e6c0a191ddc73da8f8d9 where the last command's response would be logged twice in syslog if cli file doesn't end with a new line.

[walid-git]

Moved the command logging callback to struct cli_cmd_desc as suggested by dridi so that it can be overridden per command implementation. If the sensitive command is a cache process command, the custom log implementation cannot be used in mgt and the command will be logged with the default logging of sensitive commands (command name with hidden arguments). Also addressed other minor items. Ready for another review

[bsdphk]

I have looked over this PR in relation to the VIPC work I'm doing to enable a future CERT subprocess.

This PR attacks some of the issues we need to solve, but I'm not sure those are the ones we need to or should fix first, nor that they should be fixed this particular way.

In the future world order, we will have multiple "entities" which offer CLI commands: MGT, WRK, CERT but also VMODs and VEXTs, and the MGT needs to know where (and when!) to send commands. (This also implies that we do not know all CLI commands at compile-time any more!)

We will also be passing file-descriptors around in association with CLI commands (the "smuggling" facility).

And finally we will have distinct levels of CLI authority: Being able to load a new CERT is a different authority from loading a new VCL, from adding a BAN and from mucking with a backend (for unspecified values of mucking.)

I'm as of yet undecided if we will also have CLI multiplexing, for instance being able to do a "backend.list" while a new VCL is being compiled, but I'll probably default to "Since we're ripping all this apart anyway…"

As for the logging, that's an entire different kettle of fish. It is not obvious to me that CLI logging belongs in the subprocesses after this reconstruction, maybe MGT needs to grow it's own logging facility (or just use syslog?) and be responsible for all logging related to CLI, including thinking about which authority logs where.

So I'm inclined to call this PR a very valuable prototype, and throw it away (as Brooks commands us.)