Recently, I got into a discussion with a friend of mine that I have a great deal of respect for. After having our discussion, my respect for him has grown. The discussion was about whether or not Debian and Ubuntu have deviated from standard practice regarding Paul Vixie's cron implementation.
The idea is simple. On Fedora and SUSE based operating systems, if /etc/cron.allow AND /etc/cron.deny do not exist on the system, then only the super-user can install cron jobs using the crontab command. However, on Debian and Ubuntu, both files are missing, yet everyone on the system can install a cron job. So, the question was: why does Debian and Ubuntu feel the need to be different from everyone else? Why do they need to deviate from standard practice?
Now, for the record, I don't care if Debian deviates... much. Debian is an operating system. Sometimes, I think those in the Free Software and GNU/Linux world forget that. Operating systems are free to make the changes necessary for their platform as they see fit. Those changes will likely either make users happy and make the operating system popular, like Ubuntu, or they won't be good changes, and likely will lose users, like, well, Gentoo (sorry guys, but you have seen better days). I'm all for changes that are thought out and that bring obvious or non-obvious benefits. For example, Debian Squeeze moving away from System V Init to Upstart.
So, the question remains: Is Debian deviating with Vixie cron from what would be considered "standard practice"? Well, to start, I pulled up the crontab(1) man page to see what it says regarding the matter. On Debian, this is what I found:
If the /etc/cron.allow file exists, then you must be listed therein in order to be allowed to use this command. If the /etc/cron.allow file does not exist but the /etc/cron.deny file does exist, then you must not be listed in the /etc/cron.deny file in order to use this command. If neither of these files exists, then depending on site-dependent configuration parameters, only the super user will be allowed to use this command, or all users will be able to use this command. For standard Debian systems, all users may use this command.
I pulled up the same man page on Fedora, and this is what I found:
If the cron.allow file exists, then you must be listed therein in order to be allowed to use this command. If the cron.allow file does not exist but the cron.deny file does exist, then you must not be listed in the cron.deny file in order to use this command. If neither of these files exists, only the super user will be allowed to use this command.
Both man pages document exactly what the behavior of crontab is should both /etc/cron.allow and /etc/cron.deny be missing. Further, the crontab(1) man page mentions a site-wide configuration file for this behavior. On Debian, by default, I reached for /etc/default/cron to find this configuration. Nothing in there seemed to lead me to this behavior. Pulling up /etc/sysconfig/crond on Fedora also lacked the information I was looking for. I dug through /etc/pam.d/cron, /etc/crontab, /etc/init/cron, /etc/init.d/cron, /etc/security/access and just about any other possible configuration file that might be related, and came up empty-handed every time.
So, when in doubt, Use the Source Luke. So, I went to the Debian packaging site to grab the cron source. Why there rather than upstream? Because Debian ships the upstream pristine source in one tarball with the Debian-specific patches in another tarball. This way, I can see what is being patched while staring at the source directly. While I was at it, I grabbed the source RPM from Fedora as well. However, I grabbed it from Fedora 8, as it seems Red Hat has forked Vixie cron to "cronie" around Fedora 9, and I wanted to compare apples to apples.
Now, before I dug through the source, I found one bit of information that actually started laying to rest my suspicions. Paul Vixie developed cron for BSD 4.3. So, I would imagine that Vixie cron is still running on BSD systems, and that the default, intended behavior from Paul Vixie himself would be present on the BSDs. Curious, I fired up FreeBSD, and read the crontab(1) man page:
If the allow file exists, then you must be listed therein in order to be allowed to use this command. If the allow file does not exist but the deny file does exist, then you must not be listed in the deny file in order to use this command. If neither of these files exists, then depending on site-dependent configuration parameters, only the super user will be allowed to use this command, or all users will be able to use this command. The format of these files is one username per line, with no leading or trailing whitespace. Lines of other formats will be ignored, and so can be used for comments.
Interesting. Even FreeBSD says that depending on site-wide configuration parameters, either only the super-user will be able to use crontab or everyone. This is the same wording in the Debian man page. Curious, I looked, and sure enough, both the allow and deny files are missing in /var/cron/, and yet everyone on the system can install cron jobs. This is telling me that Debian is not deviating from upstream, and that Red Hat is. However, I have the source, let's see what that says.
First, I cracked open the Fedora patches to see if the patch was obvious. To be honest, I was a bit overwhelmed by the sheer number of patches Fedora was applying. Most were for PAM and SELinux, however. But, there was a patch for the crontab(1) man page, and there was a patch against crontab itself. After a bit of digging and parsing the C files, it seemed clear to me that Red Hat was patching crontab to only allow root to install a cron job if both the allow and deny files are missing. This patch does not exist in Debian, nor could I find it in FreeBSD.
So, it seemed clear. Debian was in fact not changing the default behavior of cron, but it was Red Hat who was doing the changing. Further, despite what the documentation says, I could find no site-wide configuration file to modify this behavior- even referenced in the source code. The only way to make the change was to change the code before compilation (so maybe we should submit a bug on the man page).
Digging deeper, I learned that there are many cron systems available for GNU/Linux. It appears Arch Linux is shipping dcron by default (Dillon's cron), Red Hat has forked Vixie cron to cronie, and Debian and Ubuntu both utilize or will utilize Upstart, which will eventually replace cron entirely. It's my understanding that launchd on Mac OS X has also replaced cron (although I haven't verified).
Generally, when I got into discussions with various people about Debian or Ubuntu changing this, that or the other for whatever reason, nine times out of ten, it has been my experience that Debian is not the one deviating, but it is the one who is doing the accusing that is deviating. This example with cron has only been one. I've had discussions like this many times before. The only real solid example of Debian deviating from standard that I can come up with quickly off the top of my head, is Apache. The /etc/apache2/(sites,modules}-{available,enabled}/ directories are a break from standard. However, I have found that I prefer this configuration to upstream vanilla, as it makes administering specific modules and websites a bit easier to maintain without affecting others. This is a change that is long term beneficial to Debian.
In conclusion, what does this mean? Is Debian better than Fedora/RHEL/CentOS or any other operating system? While I prefer it on my systems, the answer is of course no. But, when breaking from standard practice is called into question, I'm glad Debian sticks as close to upstream as possible. I understand the need for patches where appropriate, but I would prefer as vanilla as possible so I'm not a fish out of water when I need to move to another operating system that is deploying the same technology. At least from that point I'll be able to see the changes the new system is making. I understand Arch Linux is about as vanilla as you can get, but until they separate the non-free from the free software and GPG sign their packages, I won't run it.
Debian it is for me, and I'm glad they have the philosophies they do.
{ 16 } Comments