Description of problem:

This is a variant of the problem already reported in Bugzilla 575419 where /etc/crontab incorrectly set HOME=/ such that the cron.daily Job was unable to make use of root-specific configuration files such as /root/.my.cnf

Because of the reworking of Cron/Anacron under RHEL6, cron.daily's environment is now effectively controlled by /etc/cron.d/0hourly which also has a HOME-/ setting. 

Our recommendation is to comment out HOME=/ from BOTH /etc/crontab and /etc/cron.d/0hourly in RHEL6 and /etc/crontab in RHEL5.


Version-Release number of selected component (if applicable):

cronie-1.4.4-7.el6.i686


How reproducible:

Create a cron.daily Job which reports HOME - by simply executing /bin/env for instance.


Additional info:

In the course of trying to debug this problem, we found two additional problems when trying to read /root/.my.cnf from within a /etc/logrotate.d/mysql script within logrotate within cron.daily.

The first problem is that /etc/cron.daily/logrotate erroneously - in our view - redirects STDOUT and STDERR to /dev/null under RHEL6, whereas it redirects into cron.daily's sendmail PIPE under RHEL5. Surely this NULLing should be removed?

The second problem is that under RHEL6, /root/* has an SELinux Label of admin_home_t whereas it had a Label of user_home_t under RHEL5. The side-effect is that logrotate_t has no read permissions to /root/* under RHEL6, even though it did under RHEL5. Consequently we added this permission to get our particular logrotate script working:

allow logrotate_t admin_home_t:dir { list_dir_perms };
allow logrotate_t admin_home_t:file { read_file_perms };

Is it reasonable to add this permission to RHEL6?