From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
Root's crontab, /etc/crontab, defines HOME to be "/". This can cause
some programs difficulty, for example autorpm
<http://www.kaybee.org/~kirk/html/linux.html>. Root's actual home
directory is "/root". Maybe /etc/crontab should define it that way.
Steps to Reproduce:
1. As root, import the RPM PGP keys from /usr/doc/rpm-xx
2. Install Autorpm & configure /etc/autorpm.d/redhat-updates for automatic
updates, with PGP signature checking
3. Let autorpm run from cron
Actual Results: autorpm will fail to verify the signatures on the RPMs.
However, when you log in as root and run autorpm manually with 'autorpm --
apply', it will be able to verify the signatures.
Expected Results: Autorpm should have been able to invoke gpg seamlessly
to check the validity of the packages.
This fails because when autorpm tries to run gpg, HOME=/. When gpg was run
earlier, it used HOME=/root to do its work. gpg will create a
new, empty /.gnupg directory when run from cron, but it will not contain
root's actual .gnupg directory.
Red Hat should consider changing crontab's HOME to /root instead of /,
unless this is considered a security flaw. This exists on at least Red Hat
7.0 and 6.2.
This was actually switched to / a few releases back. I don't recall why off the
top of my head, but there was a reason. Will have to check into it.
FYI, this problem also impacts the MySQL package, last I checked. In order for
the log rotate script to find the password file, I had to symlink /.my.cnf -
To fix this "problem", simply prepend:
to your cron job, so the cron job would look like:
* 12 * * * root HOME=/root autorpm
We do not want whatever happens to be in
to affect all cron jobs.