Image of the glider from the Game of Life by John Conway
Skip to content

Does Debian Deviate From Standards Or Upstream?

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

  1. LaserJock using Google Chrome 4.0.266.0 on GNU/Linux | January 4, 2010 at 9:19 am | Permalink

    I remember something like this when I first moved from Red Hat/Fedora to Debian. As a scientist I use gnuplot quite a bit. In Red Hat/Fedora gnuplot is compiled with readline support. In Debian it's not because of license incompatibilities. Red Hat/Fedora was more useful because I got the nice readline support, after I read up on the issue it seemed kinda "not good" for them to totally ignore the licensing issue.

  2. Watts using Safari 531.21.10 on Mac OS | January 4, 2010 at 11:27 am | Permalink

    Mac OS X's launchd is really a replacement for the /etc/init.d bootup files -- it's described as a "System-wide and per-use daemon/agent manager." The crontab man page contains an admonition that "Although cron(8) and crontab(5) are officially supported under Darwin, their functionality has been absorbed into launchd(8)." (Launchd is described as "a more flexible way of automatically executing commands"; while I suspect that's technically true, XML property lists give me hives.)

    Beyond that, it's using Vixie Cron and it has the identical paragraph about cron.allow/cron.deny that Debian does ("If neither of these files exist, 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").

  3. Aaron using Firefox 3.5.6 on Windows XP | January 4, 2010 at 2:23 pm | Permalink

    @Watts Well, most of the Mac OS X tools come out of FreeBSD, and many Apple developers are paid to develop FreeBSD directly, so the fact that Vixie cron is installed and functioning, doesn't surprise me. However, I am aware of launchd replacing System V Init just as Upstart has done the same. My point was just that the functionality of cron exists in launchd, and launchd can execute scripts and events on timed intervals or at specific times.

  4. Eugene Belford using Google Chrome 4.0.286.0 on GNU/Linux | January 4, 2010 at 2:34 pm | Permalink

    Thanks. I'm going to link to this whenever people try and tell me that Red Hat is the one with standard behavior.

  5. mok0 using Safari 531.21.10 on Mac OS | January 4, 2010 at 7:05 pm | Permalink

    I actually don't agree with you that accepting the utility authors' choice of default behaviour is by definition a good thing.

    The purpose of an operation system -- or distribution if you like -- is to provide a uniform and tested environment, and it is the privilege of the developers to define how the individual components should be configured to be consistent with the philosophy they've chosen.

    So, if that philosophy is that you need to do something special to restrict users from doing something, then you configure the utilities to work like that, if not, you do the opposite. It depends on what character you want for the OS.

    In the case of cron, I personally don't think it's much of a security risk, so I prefer the Debian/Ubuntu way of doing things. I generally do.

  6. Aaron using Debian IceWeasel 3.5.6 on Debian GNU/Linux | January 4, 2010 at 7:30 pm | Permalink

    @mok0 You didn't read the post in its entirety, did you? Quote:

    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.

    And further...

    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 think it's quite clear that I'm not blindly accepting whatever upstream decides to do. I've recognized where patches are appropriate and I've mentioned why I prefer to keep things as clean as possible. Seems to be quite obvious.

    Lastly, the post isn't about the security of users on the system. Not at all. The post is about if Debian is patching default behavior or not. I know how to restrict users from installing cron jobs, and many other aspects of the system.

    So, maybe you should read the entire post before commenting.

  7. Mackenzie using Firefox 3.5.6 on Ubuntu | January 4, 2010 at 8:22 pm | Permalink

    OSX has cron. I've used /etc/cronttab on OSX 10.4 (Tiger)

    /me unchecks "Authenticate this comment using OpenID." because it always always always fails

  8. Kamil Kisiel using Google Chrome 4.0.249.30 on Mac OS | January 5, 2010 at 1:19 pm | Permalink

    launchd does indeed have all the functionality of cron, although working with the plists is a bit more cumbersome than editing a crontab. However, there are programs that can help with the process.

    At my workplace we never use cron on our Macs and schedule everything thought launchd.

  9. JanC using Firefox 3.5.6 on Ubuntu 64 bits | January 6, 2010 at 4:27 am | Permalink

    Also a good thing to know: when Debian changes the way configuration works, that is often documented in README.Debian, e.g. the Apache 2 configuration is explained in /usr/share/doc/apache2/README.Debian.gz

  10. Brett Alton using Google Chrome 4.0.284.0 on GNU/Linux | January 6, 2010 at 1:47 pm | Permalink

    This is very interesting and insightful. I do also prefer Debian's method of packaging Apache and find it hard to use CentOS/RedHat/Fedora for that very reason. I'll stick with Ubuntu/Debian thank you very much.

    Also very interesting about cron. I always prefer the distro to stick with upstream as closely as possible unless it enhances the product, such as Apache as mentioned above.

    Also, lesson learned from libssl when the random number generator was destroyed.

  11. Carlie Coats using SeaMonkey 1.1.16 on GNU/Linux 64 bits | January 7, 2010 at 5:14 am | Permalink

    Not the first time RedHat has botched it!

    What RedHat does to the Mozilla based browsers is another extremely annoying example: if you launch a browser on a remote machine, the !*&$%^! RedHat-version browser code has been munged actually to launch a browser on your desktop rather than the machine you thought you launched it on.

    So when you're logged in to an Altix server hundreds of miles away, and you attempt to look at the HTML compiler documentation located there, your "firefox file:/opt/compiler-vendor/docs/index.html" command on the remote machine _actually_ launches a browser on your desktop, and of course "/opt/compiler-vendor/docs/index.html" doesn't exist there. It's RedHat who has munged the browser source this way (I've got the bugzilla bug around here somewhere...), as you can verify by downloading the source directly from Mozilla, and comparing.

    And this for an allegedly-server operating system on a clearly-server always-headless Itanium machine! Doesn't meet my laugh test for "server OS".

  12. Aaron using Debian IceWeasel 3.5.6 on Debian GNU/Linux 64 bits | January 7, 2010 at 6:12 am | Permalink

    @Carlie No, that's not accurate. We launch remote Firefox installs on RHEL all the time to pull up documentation, and it behaves exactly the way it should. I don't know what you're doing wrong, but you're definitely doing something wrong.

  13. Yorokobi using Firefox 3.6.3 on GNU/Linux | May 8, 2010 at 12:20 pm | Permalink

    In Archlinux, the system-wide configuration that governs whether a user can utilize cron is the 'users' group. If a user 'A' is not a member of the 'users' group, user 'A' will not have access to crontab.

    So far as I can tell, dcrod does not use /etc/cron.{allow,deny}

  14. Aaron using Google Chrome 5.0.375.29 on GNU/Linux 64 bits | May 9, 2010 at 6:55 am | Permalink

    Wait, Arch uses the "users" group? They don't use user private groups? I thought openSUSE was the only operating system that made that mistake. :)

  15. Jonathan Vasquez using Epiphany 2.30.6 on Debian GNU/Linux | March 12, 2011 at 11:12 pm | Permalink

    I also run Debian on my systems. I love Debian as I do Arch. I did leave Arch though because of the package signing issue. As for the separating non-free from free, I love GPLv2 (NOT, I repeat NOT v3) and BSD licenses and I advocate for them, but I don't mind proprietary software as well. There are wonderful proprietary software out there and it's the developers choice whether he/she wants to release their software as proprietary or not. Thus I believe this world can live in harmony with open source/proprietary software.

    Personally I believe that a distribution should be kept as close to vanilla as possible (with the occasional patch if something is _really_ required), it should be making the life of the user simple (so using well written/designed GUI tools to do the job is not a problem - even though I don't want to get overbogged by GUI apps, sometimes CLI is just much easier), and it should use the latest technologies to make an all in one desktop, and that definitely means that if proprietary software needs to be included, then so be it. We need to use our computers to complete our work, not to turn it on and be lacking something. The reason we started using computers is because of the way it helped us achieve our goals, and as a bonus we received a wonderful world to learn from.

    - Jon

  16. Jonathan Vasquez using Epiphany 2.30.6 on Debian GNU/Linux | March 12, 2011 at 11:14 pm | Permalink

    @Aaron The Arch Wiki says to add the user to the users group, but remember, Arch is what you make it ;D haha.

{ 2 } Trackbacks

  1. [...] Does Debian Deviate From Standards Or Upstream? 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). [...]

  2. firefox 3.5 debian | FIREFOX | January 26, 2010 at 1:30 am | Permalink

    [...] Aaron Toponce : Does Debian Deviate From Standards Or Upstream? [...]

Post a Comment

Your email is never published nor shared.

Switch to our mobile site