Summary: | sys-process/vixie-cron-4.1-r11: installation does not repair permissions for /var/spool/cron/crontabs/ | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Kirikaza <kirikaza> |
Component: | [OLD] Core system | Assignee: | No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | cron-bugs+disabled, treecleaner |
Priority: | High | Keywords: | PMASKED |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Deadline: | 2019-10-11 |
Description
Kirikaza
2010-01-05 10:04:31 UTC
Now that this has been open for over 5 years, is it really that difficult to fix this thing (I just ran into this)? Say crontab (group) was created during a crossmerge (or at some point in time when crontab had the gid X). If the group got removed, other packages were merged with gid=next and then vixie-cron is reinstalled, it will create a new crontab group with gid Y!=X. Since /var/spool/cron/crontabs preexists, the gid sticks and thus the dir has the wrong group and cron fails to work (without any reasonable error messages, btw.). Solution: Either warn the user to fix up the permissions of /var/spool/cron/crontabs during installation of vixie-cron, or check the mode+ownership during the start of vixie-cron (i.e. in it's init script). Package removed. |