A cron entry looks like a timestamp followed by a command. The daemon also builds an environment, selects a shell, and parses environment assignments in the crontab. Those details decide which executable a short command actually runs.

The Debian crontab(5) manual notes that environment assignments affect the commands below them in the file. It also notes that SHELL and PATH can be overridden by crontab settings, while LOGNAME and HOME come from the account. A privileged job that relies on a short command name can therefore execute a different file after someone edits PATH or adds a program to an earlier directory.

Where cron gets its environment

The review should start with the crontab file and its ownership. System crontabs must be writable only by the appropriate administrator. User crontabs should be protected by the daemon's file-mode checks. Then inspect every environment assignment. A PATH that includes . or an empty element is ambiguous. A path that begins with a user-writable directory is a privilege risk when the job runs as root.

A secure execution path

Prefer absolute executable paths for privileged jobs. If a wrapper script is used, inspect the wrapper's own command resolution and every interpreter it launches. A shell script can set PATH internally, invoke env, source a profile, or call a tool through a function imported from the environment. The crontab line is not the end of the search.

Review checklist

Useful changes include:

  • Set a fixed, administrator-owned PATH at the top of the crontab.

  • Use absolute paths for the command and its critical helper programs.

  • Start privileged jobs from a non-writable working directory.

  • Define SHELL explicitly when the script depends on shell behavior.

  • Keep environment secrets out of crontabs and world-readable logs.

  • Test the exact environment cron supplies, not an interactive shell environment.

Audit evidence

The shell itself is part of the boundary. /bin/sh may be a different implementation on another host, and a script that works interactively may fail or choose a different startup path under cron. Avoid relying on aliases, shell functions, or profile files that cron does not load. If a job needs environment values, set them explicitly and validate them before use.

Logging should record the resolved executable and a stable job identifier. An attacker who can alter a path may leave the crontab line unchanged, so a diff of the schedule alone is not enough. File-integrity monitoring for administrator-owned directories and alerts on permission changes provide useful evidence.

Cron is simple, which makes these assumptions easy to miss. A fixed path, controlled file ownership, and an isolated working directory turn a short crontab entry into a reproducible execution decision. Review that decision whenever the job, its account, or its deployment path changes.

References

  • Debian crontab(5) manual, environment and PATH behavior: https://manpages.debian.org/trixie/cron/crontab.5.en.html

  • OpenBSD crontab(5) manual, environment assignments: https://man.openbsd.org/man5/crontab.5