When setting up security context cron_set_job_security_context() calls cron_change_user() 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 vixie-cron-4.1-_60-SELinux-contains-range.patch 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[2260]: (CRON) chdir(HOME) failed: (Permission denied) Jul 25 21:04:01 gss7-102 crond[2260]: (CRON) /home/vijay (Permission denied) Jul 25 21:04:01 gss7-102 crond[2260]: CRON (vijay) ERROR: failed to open PAM security session: Permission denied Jul 25 21:04:01 gss7-102 crond[2260]: CRON (vijay) ERROR: cannot set security context This event sent from IssueTracker by sprabhu issue 126847
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 Fedora 7. 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: vixie-cron-4.1-83.fc7 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[22049]: (CRON) chdir(HOME) failed: (Permission denied) Sep 11 08:54:02 localhost crond[22049]: (CRON) /home/chris (Permission denied) Sep 11 08:54:02 localhost crond[22049]: 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 environments.
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 for us.
(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 5.2 ??
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. http://rhn.redhat.com/errata/RHBA-2008-0586.html
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.