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

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”.

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.

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

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

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.

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.

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”).