The following message was posted on oss-sec ML:""" Hi, The packages in Gentoo often utilizes Portage's functions like keepdir to create a directories, with specified permissions. One of the examples is 'cronbase', which the only purpose is to setup /etc/cron.{hourly,daily,weekly,monthly} and /var/spool/cron. The /var/spool/cron is meant to have root:cron 750, which makes the crontab usable only for the users that are members of cron group. As for the /etc/cron.{hourly,daily,weekly,monthly} they're meant to be root:root 750. If, for instance, a mlocate package will be installed before cronbase, due to installing /etc/cron.daily/mlocate, the /etc/cron.daily will end up with 755 permissions. After than when crontab package is installed, due to usage of portage's keepdir function, the directory in temporary directory will be installed as root:cron 750, but during the merge process to rootfs no directory permissions will be merged, leaving the /etc/cron.daily as 755. On one system after installing set of packages, the /var/spool/cron ended up being cron:root 755, which results in possibility for any local user to actually create the crontabs (including system users like nginx, mysql, and so on). The way a (directory) ownership and permissions are handled in Gentoo seems to be flawed, it's not clear to me whatever Portage should provided a soluton to that, or the ebuilds authors should make sure to always depends, in case of touching cronbase directories, on the cronbase package, to ensure that it's installed prior to installing them. Nonetheless I do believe this issue is worth CVE. -- Piotr. """ Is there any comment from the portage team on this?
(In reply to Kristian Fiskerstrand from comment #0) > The way a (directory) ownership and permissions are handled in Gentoo seems > to be flawed, Yeah it's bug 141619, and there's a proposal for resolving conflicts in bug 396153. > it's not clear to me whatever Portage should provided a > soluton to that, or the ebuilds authors should make sure to always depends, > in case of touching cronbase directories, on the cronbase package, to ensure > that it's installed prior to installing them. Nonetheless I do believe this > issue is worth CVE. > > -- Piotr. > """ > > Is there any comment from the portage team on this? An alternative to the dependency-based approach would be for cronbase to force the permissions in pkg_postinst.
In regard to cron directories, yes. But I suspect they may be some other packages out there that suffer from the same thing. Did you ever considered a mechanism, similar to the dpkg-statoverrride, that would allow packages to register particular permissions for files/directories to enforce permissions, so even if a package merges with, for example, 755, portage would force it to 750? I think this is something that could be done even on bashrc level with post_pkg_postinst hook to adjust the on-rootfs permissions as well as do the same on pre_pkg_merge to adjust them in $D, so in case that they don't exist on rootfs, they would be merged with the globally enforced permissions.
This is a duplicate of bug 607426.
*** This bug has been marked as a duplicate of bug 607426 ***
