Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

The /etc/crontab file has the permissions:

-rw-r--r--

I understand that this file is for system cron jobs and other users should not have permission to modify it. The current permissions allows all users read access to the file, enabling them to view the contents.

Is it necessary for all users to be able read /etc/crontab? I believe that all users should not know some administrative commands, so wouldn't it be better to change the permissions to -rw-r-----?

I used the permission string from CentOS and have not tested it on other distros.

share|improve this question

2 Answers 2

This would be security by obscurity. There is no real benefit by preventing normal users from reading /etc/crontab. Even if a user can't read the file, it's still possible to gather the executed command just by regularly capturing the process list with ps or by reading /proc.

There should be no need at all to hide some administrative commands except when you put credentials in the command-line. But you should never put credentials in the command line anyway as a normal user can read the command-line, so no real benefit.

There is a mount option/kernel patch for procfs preventing PID leakage as well as some kernel modules like grsec which prevent PID leaks.

The benefit of having the file system readable is that you can have a look/debug the system as a non root user. You don't have to switch to the root user just to check the system crontabs.

share|improve this answer
    
I disagree somewhat. It is not merely "security by obscurity" to want to keep cronjob details away from regular users. I would call it a (small) part of "defense in depth". Basically, you're right, someone could POSSIBLY determine the contents of my crontab by watching all processes over a length of time, but IMO, that's just fine. Any extra amount of time that a non-root intruder is forced to spend to analyze weaknesses in my system is extra time that I GAIN to detect his presence and take remedial action. –  Steven Monday May 18 '12 at 22:26
    
@StevenMonday I disagree somewhat: making /etc/crontab non-world-readable isn't so much security by obscurity as pointless. I would not store confidential information there. The times the jobs run are not confidential information, not even to a defense-in-depth level, to someone with an account on the machine. –  Gilles May 19 '12 at 13:17
    
@Gilles: Looks like we agree to disagree. Somewhat. ;-) –  Steven Monday May 20 '12 at 3:26

/etc/crontab is the main - crontab - resposible for triggering cron.daily, weekly, ...

So if a user wants to know when daily/weekly and so on are being run he/she should be able to check that (fixed time on CentOS, relative time from system boot in SLES).

But actual root-jobs should be placed at /etc/cron.d/specialtime_user, /etc/cron.daily/* and so on, or will be placed in /var/spool/cron/root. The former is sometimes a little bit strange - regarding access rights (I stubled across that on SLES, where I tried to set more restrictive rights on a file there) - the latter should be readable only by root.

share|improve this answer
    
This argument makes sense to me: /etc/crontab on a CentOS box just isn't interesting enough to bother making it unreadable to normal users. –  Warren Young May 21 '12 at 21:16
    
"/etc/crontab is the main - crontab - resposible for triggering cron.daily, weekly" - That is only true for Debian. See the crond(8) manpage. –  Adam Monsen Apr 24 at 18:52
    
@Monsen and for SLES 10, 11 and RHEL 5, and... –  Nils Apr 25 at 9:14

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.