6

I'm working on a production server. It has some daily cron jobs, and here's the filesystem permissions on them:

cron.daily$ ls -Al
total 24
-rwxr-xr-x 1 root root  332 Dec  3 10:33 0yum-daily.cron
-rwxr-xr-x 1 root root 2239 Jun  9  2014 certwatch
-rwxr-x--- 1 root root  953 Aug 29  2015 gdrive-backup
-rwx------ 1 root root  180 Jul 31  2013 logrotate
-rw-r--r-- 1 root root  618 Mar 17  2014 man-db.cron
-rw-r----- 1 root root  192 Jan 26  2014 mlocate

All but one of the jobs is from CentOS or the hosting provider; while one job is ours. The permissions spread the spectrum.

Our job is gdrive-backup, and its got hard coded usernames and passwords. We did not feel it appropriate to give the world read access to it.

What are the permissions supposed to be on a cron job when it sits on the filesystem?

Here is the cat of crontab, which (I think) shows there's nothing special going on:

$ cat /etc/crontab 
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin

# For details see man 4 crontabs

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name  command to be executed

$

A related question is What are the runtime permissions of a cron job?, but it discusses the user credentials the job runs under, and not the filesystem permissions.

Community
  • 1
  • At the minimum, the script you are running through cron, must be executable by the user running it. Assuming the ls output in your question is for root user, the jobs 0yum-daily.cron, certwatch, gdrive-backup and logrotate can run via cron or from the command line interactively. – MelBurslan Mar 29 '16 at 13:39
  • Thanks @MelBurslan. The ls is from my user account. Its mostly unprivileged, but with sudo access. I also visited CentOS's manual, and it clearly stated cron was the recurring job manager. There's no other recurring schedulers discussed. –  Mar 29 '16 at 13:46
  • if your jobs are reaching into any directories and files to read and write, again, the permissions of those needs to be openenough for the user running the job. Since you are running these jobs with sudo, it should not matter, as your effective UID is 0, i.e. you are root. Unless of course you are touching any NFS file systems, where the access rights are managed by the server, not by your local machine only. Google Drive might be a potential problem, depending on your setup. – MelBurslan Mar 29 '16 at 13:53
  • Thanks again @MelBurslan. Man, I thought this was going to be easy. Boy was I wrong... I [naively] presumed something like "owner is root or cron, group and other don't matter and can be removed". Do you even know if everything should be executable or not? That's what caught my eye first. –  Mar 29 '16 at 14:29
  • executable requirement is only for the scripts you run through cron. Whatever files and directories those scripts are reaching and touching is governed by the unix ownerships and permissions. Being executable is not a requirement at that point – MelBurslan Mar 29 '16 at 14:35

1 Answers1

4

On CentOS, the daily cron job gets executed as

/usr/bin/run-parts /etc/cron.daily

run-parts is a shell script. It looks through the contents of its argument (a directory), filters out things such as files that end in ~, .swp, .rpmsave, and directories, then for every file that passes the test if [ -x $i ], that is, executable by root, it runs the file.

So all the files in /etc/cron.daily that have any x bit at all turned on will be run. You can set the permissions on those files to deny read access to everyone, if you wish; it doesn't matter to root. If you have embedded passwords in the scripts that may be passed as arguments to commands, note that all /proc/*/cmdline files are publically readable, so all users can see all commands and arguments as they're being run.

Mark Plotnick
  • 25,413
  • 3
  • 64
  • 82