Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 262768 - crontab group access should be better documented
Summary: crontab group access should be better documented
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-17 05:55 UTC by Gil Kloepfer
Modified: 2023-01-28 20:20 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gil Kloepfer 2009-03-17 05:55:52 UTC
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.
Comment 1 Gil Kloepfer 2009-03-17 06:05:21 UTC
(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.
Comment 2 Arthur Hagen 2009-03-17 20:51:18 UTC
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.
Comment 3 Gil Kloepfer 2009-03-17 21:05:17 UTC
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.
Comment 4 SpanKY gentoo-dev 2015-07-23 07:10:26 UTC
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.