The permissions on /var/spool/cron as set by sys-process/cronbase is 750/root/cron, and sys-process/vixie-cron puts a directory called crontab under /var/spool/cron (owned by group crontab, not cron) and the crontab command is sgid crontab. As a result, a non-root user who has permission to use the crontab command cannot because the permissions on /var/spool/cron prevent access to the /var/spool/cron/crontab directory. Reproducible: Always Steps to Reproduce: 1. Install sys-process/cronbase 2. Install sys-process/vixie-cron 3. Add a non-root user to /etc/cron.allow 4. Let that user attempt to use the crontab command (ex: crontab -e) Actual Results: limbic$ crontab -e cannot chdir(/var/spool/cron), bailing out. /var/spool/cron: Permission denied Expected Results: limbic$ crontab -e no crontab for gil - using an empty one {enter editor} There are three ways to fix this: One would be to have the same group for cronbase and vixie-cron, so the directories would have the same group ownership. The other is a workaround I used, and that was to manually set the permission on /var/spool/cron to 751 instead of 750. However, sys-process/cronbase will reset these permissions, breaking my workaround, if cronbase gets an update or is re-emerged (see ebuild for cronbase, there are some specific references to bug #141619, which has a long discussion about directory permission consistency). If my workaround (/var/spool/cron permissions set to 751) is the correct fix, then the cronbase ebuild needs to be updated to reflect this. A third way to fix this is to relocate the /var/spool/cron/crontab directory. However, I think there may have been a good reason for putting the crontab directory where it is, and therefore this option is not likely a good fix.
(In reply to comment #0) > 750/root/cron, and sys-process/vixie-cron puts a directory called crontab under I mistakenly reference the directory in several places in this bug as /var/spool/cron/crontab instead of /var/spool/cron/crontabs (with an s at the end). The bug is valid, but my spelling of the directory wasn't!! Sorry about that.
To quote http://www.gentoo.org/doc/en/cron-guide.xml : "No matter which cron package you use, if you want to allow a user to use crontab, he will first have to be in the cron group." I.e. adding the user to cron.allow (or removing him from cron.deny) is not enough.
Thanks for the tip. This solved my problem, and I was able to undo my workaround. I'd suggest, then, that this be added to the man page for the crontab command rather than just having it on the cron guide in the online manual. For those of us who have used the *NIX cron system for years, we're typically not going to go to a guide telling us how to use cron. On other Linux distros (RHEL for one) needing to be in a specific group to use the crontab command is not a requirement. To emphasize, I think that the requirement to be in the cron group to use crontab is a good idea (it is consistent with similar Gentoo access controls), but I also feel it would be helpful for this to be documented in the crontab manual page on Gentoo as well.
there is no central crontab man page (every cron implementation installs their own copy). if a cron implementation is installing with setgid cron perms on the binaries, then we should probably change that so it's consistent with the others.