Description of problem: "crontab -l" attempts to access nonexistant $HOME/cron/ directory. Version-Release number of selected component (if applicable): vixie-cron-4.1-38 How reproducible: 100% Steps to Reproduce: 1.crontab -l 2. 3. Actual results: cron/ellson: Permission denied Expected results: distable cron jobs Additional info: Reverting to vixie-cron-4.1-36 fixes the problem
Oops, sorry about that - an over-enthusiastic PAM maintainer changed the PAM configuration file without any cron testing or checking with me. I'm now backing out the change until the new PAM is working correctly, and my new enhanced cron is released next week and I've had time to test. vixie-cron-4.1-39 is now in Rawhide - it should behave identically to the vixie-cron-4.1-36 you're already using, so no need to upgrade.
vixie-cron-4.1-39 contains the same problem as vixie-cron-4.1-38
Very sorry for the problems and confusion. The cause of this problem was that the 6755 setuid/setgid mode of /usr/bin/crontab was dropped . It seems that RPM no longer allows implicit setuid/setgid files - ie. if you 'chmod 6755 $RPM_BUILD_ROOT/usr/bin/crontab' in the .spec %install, and then in %files: ' %files ... /usr/bin/crontab ' the 6755 mode is not maintained - I needed to do '%attr(6755,root,root) /usr/bin/crontab '. /usr/bin/crontab MUST be installed setuid/setgid in order to have permission to modify the /var/spool directory, which is the cron 'working directory' to which the 'cron/user' you mention above is relative. This setuid crontab requirement is likely to disappear in the enhanced cron version I am working on. You can workaround this problem by , as root, doing: # chmod 6755 /usr/bin/crontab The last modifier of vixie-cron did not notice crontab was no longer installed setuid and hence would always fail for non-root users - sorry you had to find this out the hard way. The new vixie-cron-4.1-40.FC5 that fixes this problem is now submitted and will be in tomorrow's rawhide-20051018 .
It was fixed in 4.1-40.FC5, in devel has to work properly.