cronbase that installs /var/spool/cron sets up the wrong permissions there. Although ebuild seems to attempt to make it root:cron 750, the directory /var/spool/cron (and /etc/cron.*) is installed as cron:root 755, which allows any system user to setup crontabs, regardless of the cron group membership. On a gentoo system installed two years ago, the permissions are root:cron 750. diropts -m0750 keepdir /etc/cron.{hourly,daily,weekly,monthly} keepdir /var/spool/cron/lastrun diropts -m0750 -o root -g cron keepdir /var/spool/cron Maybe the diropts does not works as ebuild author intended, or maybe there is a bug in portage. Nonetheless, I'd consider it as a major security issue. sys-apps/portage-2.3.3 sys-process/cronbase-0.3.7-r6
So, it seems that if the dirs exist (because for example, vixie-cron was installed before, or anything has been added into /etc/cron.daily, the keedir of cronbase will not adjust permissions. Meaning if one emerges other packages prior to cronbase, the system is vulnerable.
as portage does not copy permissions on dirs from $D during merging to rootfs (which seems resonable) shouldn't everything that installs anything in /var/spool/cron and /etc/cron.* depends on cronbase, to make sure it is installed (and permissions are set) prior to installing own files there?
The directory permissions come from the first package to install the directory, due to bug 141619.
*** Bug 605816 has been marked as a duplicate of this bug. ***
*** Bug 607430 has been marked as a duplicate of this bug. ***
I do not think a status unconfirmed is right one. Anyhow. I've found what does make the /var/spool/cron be cron:root 755. When merging cronbase for the first time the cron user is created with home set to /var/spool/cron. >>> Emerging (1 of 1) sys-process/cronbase-0.3.7-r6::gentoo openpty failed: 'out of pty devices' * Adding group 'cron' to your system ... * - Groupid: 16 * Adding user 'cron' to your system ... * - Userid: 16 * - Shell: /sbin/nologin * - Home: /var/spool/cron * - Groups: cron * - GECOS: added by portage for cronbase * - Creating /var/spool/cron in / And then the ebuild have the keepdir with right right permissions, but since the /var/spool/cron will exist before it gets to the keepdir, nothing is really applied.
In cronbase-0.3.3.ebuild we had chown/chmod in pkg_postinst, which we don't have in later versions: https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-process/cronbase/cronbase-0.3.3.ebuild?id=ca727c9567a7ac4023ade8cce10e26a6376c2cae
The pkg_postinst was dropped by vapier in the version bump to 0.3.4: https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-process/cronbase/cronbase-0.3.4.ebuild?revision=1.1&view=markup
I think I understand the problem with /var/spool/cron being 755. But I have a much harder time with /etc/cron.*. Can someone explain what problem is solved by setting them to 750? Other than the cronjobs there just being readable by everyone - which is a good thing, IMO, just like a world readable /etc/passwd is. If there is an exceptionally badly written job that contains secret info one can always just set the job itself to mode 700, or not?
