Bug 299716

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

Installation does not deals with permissions for dir `/var/spool/cron/crontabs/' if the dir exists already.

Reproducible: Always

Steps to Reproduce:
1. chmod 700 /var/spool/cron/crontabs
2. chown root:root /var/spool/cron/crontabs
3. emerge -1 =sys-process/vixie-cron-4.1-r11

Actual Results:  
Installation finishes successfully but it neither change mode/group nor say anything about wrong mode/group.

Expected Results:  
It should warn of wrong permissions. E.g. `net-mail/mailbase' do that.

Comment 1 Sven E. 2017-04-22 15:54:39 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).

Comment 2 Michał Górny archtester

2019-10-11 15:07:50 UTC

Package removed.