Red Hat Bugzilla – Bug 241877
Cron does not handle home directories with group deny permissions
Last modified: 2014-09-08 10:27:15 EDT
When setting up security context cron_set_job_security_context() calls
cron_change_user() sets gid first then attempts to chdir(homedir). If a user's
home dir has group deny permissions (e.g. rwx---r-x) this fails and errors are
reported in /var/spool/cron, e.g.:
(CRON) chdir(HOME) failed: (Permission denied)
CRON (xxxxx) ERROR: cannot set security context
This bug seems to have been introduced by the
Attached patch moves the homedir check after setuid()
Created attachment 155800 [details]
Patch to moves the homedir check after setuid()
Already fixed in devel.
The problem of trying to chdir before doing setuid can also be seen on
setups where the home directory is mounted over the nfs share. If the
share is mounted with the root_squash options which is the default, the
chdir will fail causing the same error messages.
This is seen in the strace
1940 19:41:02 setgid(2002) = 0
1940 19:41:02 chdir("/home/vijay") = -1 EACCES (Permission denied)
I have confirmed that the attached patch fixes the issue.
Steps to recreate:
1) Export a user home directory. Do _not_ add no_root_squash option to the
exports file. This directory should be owned by user uid.gid and should
have permissions set to 700
2) mount the home directory on a client machine. Check to see with a su -
user to see if directory is setup correctly.
3) set the following user crontab
* * * * * /bin/ls ~ > /tmp/out-ls
4) check /var/log/cron.
The cron job should fail with the following messages
Jul 25 21:04:01 gss7-102 crond: (CRON) chdir(HOME) failed:
Jul 25 21:04:01 gss7-102 crond: (CRON) /home/vijay (Permission
Jul 25 21:04:01 gss7-102 crond: CRON (vijay) ERROR: failed to open
PAM security session: Permission denied
Jul 25 21:04:01 gss7-102 crond: CRON (vijay) ERROR: cannot set
This event sent from IssueTracker by sprabhu
I have been suffering from this bug due to a NFS mounted /home.
I have tried installing the latest RPM from testing,
vixie-cron-4.1-83.fc7.x86_64.rpm and also the rpm from Fedora 8,
vixie-cron-4.1-85.fc8.x86_64.rpm and after installing each I restarted crond but
still the problem is present.
So I thought I'd apply the patch and rebuild the RPM but the
vixie-cron-4.1.tar.gz file in the srpm doesn't contain security.c so this isn't
an option either...
Am I doing something daft?
Oops, I have just realised that this is a RHEL bug -- my problems are with
However taking the RHEL SRPM, vixie-cron-4.1-70.el5.src.rpm and applying the
attached patch (by editing vixie-cron-4.1-_60-SELinux-contains-range.patch) and
then rebuilding the RPM has solved the problem for me.
This does appear to still be a bug in Fedora 7 and 8.
Somehow I didn't add the patch to F-8 and FC-7, thank you for letting me know.
I now running this version of vixie cron on F7:
If I add the suggested lines above to my crontab:
* * * * * /bin/ls ~ > /tmp/out-ls
And tail the /var/log/cron file I have these errors:
Sep 11 08:54:02 localhost crond: (CRON) chdir(HOME) failed: (Permission
Sep 11 08:54:02 localhost crond: (CRON) /home/chris (Permission denied)
Sep 11 08:54:02 localhost crond: CRON (chris) ERROR: failed to open PAM
security session: Permission denied
I have /home nfs mounted.
Fix of this problem will be in update vixie-cron-4.1-84.fc7.
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. This request will
be reviewed for a future Red Hat Enterprise Linux release.
Please fix this bug in the current release. This is a show-stopper in NFS
It is unacceptable to have to let all clients to have root access to NFS homes
(or setting x on world) just for be able to run cron. Please , this is severe
(In reply to comment #9)
> This request was evaluated by Red Hat Product Management for
> inclusion, but this component is not scheduled to be updated in
> the current Red Hat Enterprise Linux release. This request will
> be reviewed for a future Red Hat Enterprise Linux release.
This bug MUST be fixed ! NFS home folders are used in a LOT of enterprise.
Waiting for RHEL 6 is not a option ! Why can't you back port the fc7 fix to RHEL
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.
The errata for the fix is superseded by another fix that seems to reintroduce the same problem. I have just upgraded the vixie-cron to the latest version and I am getting this exact problem in the 32bit version.
(In reply to comment #25)
> The errata for the fix is superseded by another fix that seems to reintroduce
> the same problem. I have just upgraded the vixie-cron to the latest version and
> I am getting this exact problem in the 32bit version.
Our test suite didn't find any regression. Could you provide more information e.g. version of your system, package,...
I am using Red Hat 5.2 and I had an identical problem to this. I loaded the version vixie-cron-4.1.77.el5_4.1 and this continued to be the issue.
It only worked after adding world execute and read permissions to the users nfs mounted home directory. This is not an acceptable solution as we prefer to have those not open on user accounts. What other information do you require?
(In reply to comment #27)
> What other information do you require?
1. Could you provide your audit.log?
2. Do you have any modifications of pam settings?
3. Relevant mount entries would be useful too, together with any special nfs server settings you use
4. How updated is rest of the system (selinux policies, pam updates, nfs etc)?
I tried reproducing using nfs mounted home with permissions set to go-rwx and cron was able to read/write directory. Root was unable to access directory but cron was, which implies that it is not the same bug as described here. So please, verify your settings once again.