crontab: don't reject non-string-like shell commands - #47
Merged
Conversation
yo8192
requested changes
Mar 15, 2026
yo8192
left a comment
Owner
There was a problem hiding this comment.
Thanks for raising this and preparing this!
The use of get_string to parse and assign shell commands to jobs
requires that shell commands starting with quotes also terminate with
quotes, like
* * * * * "/root/my script"
This improperly rejects commands generated by Git maintenance, which
look like (just one example)
32 1-23 * * * "/usr/libexec/git-core/git" --exec-path="/usr/libexec/git-core" -c credential.interactive=false -c core.askPass=true for-each-repo --keep-going --config=maintenance.repo maintenance run --schedule=hourly
Simpler commands with internal quotes are of course unaffected.
But why are we interpreting shell syntax anyway? That requires a fairly
complex parser.
Instead, do what the documentation says and take the rest of the
(logical) line as the shell command to execute, leaving it to the
shell's parser to interpret the commands. In case we want to later add
some validation of our own, hide this new parsing behind the abstraction
"get_command". Keep removing blanks, since they should be ignored by the
shell anyway.
While at it, add (some) test coverage for the various read_* functions
that parse job lines; these tests are only interested in the shell
parsing for now. Note that the compilation recipe for these tests is a
bit different than other recipes, since it builds based on fcrontab
(where fileconf.o is used). We also have to expose the functions to test
via the header.
Fix: yo8192#46
Contributor
Author
range-diff (
|
Contributor
Author
|
Salut @yo8192 , just a nudge in case you find time soon to give this a look :) |
yo8192
reviewed
Mar 20, 2026
…d function descriptions.
yo8192
approved these changes
Mar 22, 2026
benknoble
commented
Mar 23, 2026
Comment on lines
+1
to
4
| #include <stdarg.h> | ||
| #include <stddef.h> | ||
| #include <setjmp.h> /* setjmp.h is needed by cmocka.h */ | ||
| #include <cmocka.h> |
Contributor
Author
There was a problem hiding this comment.
Hm. FWIW, the cmocka docs state (and on my system they were right!) that the first 3 are implied by #include <cmocka.h>.
benknoble
commented
Mar 23, 2026
Comment on lines
33
to
36
| int read_shortcut(char *, cf_t *); | ||
| void read_arys(char *, cf_t *); | ||
| void read_freq(char *, cf_t *); | ||
| void read_period(char *, cf_t *); |
Contributor
Author
There was a problem hiding this comment.
I'm still not sure what provides cf_t in this header, without global.h
Contributor
Author
|
Any chance we'll see a new release with this fix soon? |
Owner
|
I'll try to find a bit of time to cut a new release in the coming weeks.
…On Fri, 27 Mar 2026 at 20:57, D. Ben Knoble ***@***.***> wrote:
*benknoble* left a comment (yo8192/fcron#47)
<#47?email_source=notifications&email_token=ABPHBIQ5V4E64OU7YIW556L4S3TK3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJUGUZDCNJVG4ZKM4TFMFZW63VMON2GC5DFL5RWQYLOM5S2KZLWMVXHJNLQOJPWG33NNVSW45C7N5YGK3S7MNWGSY3L#issuecomment-4145215572>
Any chance we'll see a new release with this fix soon?
—
Reply to this email directly, view it on GitHub
<#47?email_source=notifications&email_token=ABPHBIQ5V4E64OU7YIW556L4S3TK3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJUGUZDCNJVG4ZKM4TFMFZW63VMON2GC5DFL5RWQYLOM5S2KZLWMVXHJNLQOJPWG33NNVSW45C7N5YGK3S7MNWGSY3L#issuecomment-4145215572>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABPHBIXTL62ID3FTYGEK5H34S3TK3AVCNFSM6AAAAACWSQR4MGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCNBVGIYTKNJXGI>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The use of get_string to parse and assign shell commands to jobs
requires that shell commands starting with quotes also terminate with
quotes, like
This improperly rejects commands generated by Git maintenance, which
look like (just one example)
Simpler commands with internal quotes are of course unaffected.
But why are we interpreting shell syntax anyway? That requires a fairly
complex parser.
Instead, do what the documentation says and take the rest of the
(logical) line as the shell command to execute, leaving it to the
shell's parser to interpret the commands. In case we want to later add
some validation of our own, hide this new parsing behind the abstraction
"get_command". Keep removing blanks, since they should be ignored by the
shell anyway.
While at it, add (some) test coverage for the various read_* functions
that parse job lines; these tests are only interested in the shell
parsing for now. Note that the compilation recipe for these tests is a
bit different than other recipes, since it builds based on fcrontab
(where fileconf.o is used). We also have to expose the functions to test
via the header.
Fix: #46
Notes: On my (amd64) system, cmocka-2.0.2 was required (current in testing on Gentoo). It might be worth writing that down somewhere, and I think it's a similar issue to https://gitlab.com/cmocka/cmocka/-/work_items/38 in that it was fixed but I can't compile use the Gentoo-stable 1.1.8. I've reported that to Gentoo, so not something you need to worry about here. Just wanted to leave a breadcrumb.