I disagree with Gentoo's current policy of making /usr/bin/crontab only executable by the `cron' group. Access control to crontab is already provided by /etc/cron.{allow,deny}. I see no reason to impose an extra system, and it is troublesome when sharing a network with other Linux distributions.
Shrug... http://www.gentoo.org/doc/en/faq.xml#crontab
I'm not sure what you are trying to say with that link. As ought to be obvious from what I wrote, I am perfectly aware that one currently has to add users to the cron group, and that it is that behavior which I have reported as a bug -- not that it would somehow not be working.
Yes, so - it works perfectly fine and isn't confusing like hell - unlike cron.{allow,deny} which changes it's behaviour depending on whether the other file exists or not. I don't see the bug, sorry.
The problem is fourfold: 1. It is not the standard behavior. Every other Linux distro and Unix system in the world uses /etc/cron.{allow,deny}. Therefore, it is confusing. 2. It is also nonstandard in that way that by default (or by deleting /etc/cron.allow), users are always allowed to use cron. In Gentoo, there's no way to get that behavior (and it is therefore less functional). Users chmodding /usr/bin/crontab will also see that behavior revoked the next time vixie-cron gets emerged, unlike cfgpro files. 3. When using multiple systems in one network, one has to make special provisions for the Gentoo machines. 4. /etc/cron.{allow,deny} still remain as ways for access control. It is quite ugly to impose two access control systems simultaneously. For that matter, I fail to understand what would be confusing with /etc/cron.{allow,deny}. The behavior is clearly described in the manpage. Why not make this selectable by way of a USE flag? Alternatively, patch crontab such that a notation like "@group" can be used in /etc/cron.{allow,deny}, and ship the default configuration with a cron.allow file which contains "@cron".
you're assuming that every cron utilizes /etc/cron.{allow,deny} which couldnt be further from the truth ... every cron implementation does it their own way but many dont have any such control mechanism also, there is nothing stopping you from changing the permissions on your crontab binary and when you do, portage wont reset the permissions if you want to make a case for setting the default *vixie-cron* crontab for being executable by all, go for it ... but trying to change all the crons in portage is not going to happen ever
Indeed, fair enough -- it is vixie-cron that I wish to change. I'm left wondering about the other thing you wrote, though: > also, there is nothing stopping you from changing the permissions on your > crontab binary and when you do, portage wont reset the permissions Not so in my experience: # ls -l /usr/bin/crontab -rwsr-xr-x 1 root cron 31600 2006-06-04 21:22 /usr/bin/crontab # emerge -1va vixie-cron [...] # ls -l /usr/bin/crontab -rws--x--- 1 root cron 31600 2006-07-05 03:50 /usr/bin/crontab Of course, this includes any emerge -Duva world.
yeah, i'll research that bit and follow up with portage team
any news? looks a bit like this bug turned into a supposed portage bug... perhaps it can be transformed into such then...
closing due to no activity for more than two years. if the problem persists, please open a new bug report. your participation is apreciated. thank you. kind regards Thilo
