Adding cronjob with backslash in it

Hello,

First of all, thank you for hestia!

I am trying to add a cronjob for a user. A cronjob that has a backslash in the command:
[ $(date -d +1day +\%d) -eq 1 ] && wget -O /dev/null -o /dev/null -q https://.....

If I enter the job with the backslash in it, the backslash is being removed from the command. In the cronjobs listed for the user I can see:
[ $(date -d +1day +%d) -eq 1 ] && wget -O /dev/null -o /dev/null -q https://.....

That’s weirdo 1

Now, if I try to edit this cronjob in the GUI (click on the pencil job), I get to the edit page with all the fields empty, like if I was adding a new cronjob.

That’s weirdo 2.

Now, since that backslash didn’t make it to the command, I thought I would enter it with 2 backslashes:
[ $(date -d +1day +\\%d) -eq 1 ] && wget -O /dev/null -o /dev/null -q https://.....

Whoopsie, this returns a 500 error when listing the cronjobs for that user in the GUI.

That’s weirdo 3.

I was able to delete this cronjob by using v-delete-cron-job, after which the 500 error was gone.

While working on this, I found that the output of
v-list-cron-job <user> <nr>
is missing the “MONTH” value

That’s weirdo 4.

Is this behavior a bug, is it reproducible by someone?
Thank you.

backslashes always causing issues as it is also used to escape things.

Solution would be to place your code into a script and trigger that script over cron.

2 Likes

While I agree that backslashes are also used to escape things, I don’t think this is an excuse to not proper escape in-/output. It is just not right that a system produces an error (in this case 500) after a specific user input.

I can of course put the command in a script and trigger it by cron. No problem. But it should not be necessary. User input should be properly verified and taken care of. Not properly verifying user input before processing can lead to vulnerabilities.