/etc/cron.d /etc/cron.{hourly,monthly,daily,weekly} /var/spool/cron /var/spool/cron/lastlog /var/spool/cron/crontab and the binaries /usr/bin/cron... /usr/sbin/cron... all have different permissions. I realize that some of those differences make sense, but some don't. For instance, /var/spool/cron/lastlog should have cron group. /etc/cron.d should be 750. The files in /etc/cron.{hourly,...} should be 750. We should eclass this and clean it up. Reproducible: Always Steps to Reproduce:
we already have a cron eclass
Good call. By the way, are any of the devs interested in merging /var/spool/cron/crontabs and /etc/cron.d for vixie-cron? I just thought it was kind of awkward to have two different directories basically serve the same purpose. If anyone is, I have a modified vixie-cron-gentoo patch.
We can't change persmissions of existing files in /etc (that's a portage setting). Are you using any of the permission-related FEATURES?
What kind of permission-related FEATURES are there in portage? Other than suidctl and sfperms.
vixie-cron manpage also says: --- CAVEATS In this version of cron, /etc/crontab must not be readable or writable by any user other than root. In other words, it should be mode 0600. --- But portage seems to install it as 0644.
> In this version of cron, /etc/crontab must not be readable or writable by any user other than root. In other words, it should be mode 0600. Well I was hoping this was another perms bug caused by the new cron.eclass transition (not the eclass but the ebuild), but it looks like the vixie ebuild has always installed it 0644 either explicitly or implicitly (its the default mode for doins).
Also just noticed that the perms of /etc/crontab probably don't matter since we also install the crontab (albeit the wrong one, I also just noticed) into /usr/share/doc/${PF}.
Yep. The installed one works, but I think the right one is being put into the doc.
For remaining permissions issues, see Bug 182998. This is dead, cron eclass in place, closing.
