If the Subject header contains a command you want to run, you are exposing yourself to an arbitrary code execution vulnerability if someone can learn or guess what your email looks like. But something like this:
:0
* ^From www@your\.server\.example\.net
* ^X-Secret-Header: pA$$w0rd!\?
| formail -czxSubject: | sh
The more conditions and the more specific conditions you can put in to guard this, the smaller the risk that this can be exploited. I would still be extremely hesitant to put this on a production server. If you can put in a condition to only allow a handful of very specific commands (no rm
, no cat
, no ls
, no cp
, no sh
or su
or sudo
obviously) then mmmaybe.
Here is a variation which allows for just one particular command:
:0
* ^Subject: adduser \/[a-z0-9_]+
| sqlite3 -d users -u db -e "insert into table users (name) with value ($MATCH)"
(My SQL syntax is probably off the wall; sorry.)
Here's with your example from the updated question:
:0
* ^Subject: \/cloudron clone --app store --backup latest —location [a-z0-9]+
| $MATCH </dev/null
... or perhaps better from a security point of view to allow only the parameter to be specified:
:0
* ^Subject: cloudron clone \/[a-z0-9]+
| cloudron clone --app store --backup latest --location "$MATCH" </dev/null
These examples demonstrate how to capture something into MATCH
with the special regex operator \/
and we rather whimsically pipe the incoming message to a command which will simply ignore its standard input (we basically run it for the side effects). This will incidentally cause Procmail to regard the message as delivered; add a c
flag to avoid that (:0c
).
Many Procmail examples allow for arbitrary whitespace after the Subject:
colon etc but since these messages will presumably be machine-generated, that's an unnecessary complication here.
This will not cope correctly with MIME RFC2047-encoded headers; if you require that, you will need to add a decoding step (Perl one-liner?)