What are the filesystem permissions for a cron job

cronpermissions

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.

Best Answer

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.

Related Question