Bug 241877 - Cron does not handle home directories with group deny permissions
Cron does not handle home directories with group deny permissions
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: vixie-cron (Show other bugs)
5.0
All Linux
high Severity medium
: ---
: ---
Assigned To: Marcela Mašláňová
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-31 07:59 EDT by iain.calder
Modified: 2014-09-08 10:27 EDT (History)
8 users (show)

See Also:
Fixed In Version: RHBA-2008-0586
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-07-23 09:03:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to moves the homedir check after setuid() (870 bytes, patch)
2007-05-31 07:59 EDT, iain.calder
no flags Details | Diff

  None (edit)
Description iain.calder 2007-05-31 07:59:03 EDT
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()
Comment 1 iain.calder 2007-05-31 07:59:03 EDT
Created attachment 155800 [details]
Patch to moves the homedir check after setuid()
Comment 2 Marcela Mašláňová 2007-07-02 06:28:38 EDT
Already fixed in devel.
Comment 3 Issue Tracker 2007-07-25 11:37:00 EDT
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
Comment 4 Chris Croome 2007-08-20 06:52:15 EDT
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?
Comment 5 Chris Croome 2007-08-20 07:14:50 EDT
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.
Comment 6 Marcela Mašláňová 2007-08-21 04:11:29 EDT
Somehow I didn't add the patch to F-8 and FC-7, thank you for letting me know.
Comment 7 Chris Croome 2007-09-11 04:13:43 EDT
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.
Comment 8 Marcela Mašláňová 2007-09-11 05:12:20 EDT
Fix of this problem will be in update vixie-cron-4.1-84.fc7.
Comment 9 RHEL Product and Program Management 2007-12-03 15:43:14 EST
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.
Comment 10 Dominic Lepiane 2008-02-26 12:04:50 EST
Please fix this bug in the current release.  This is a show-stopper in NFS
environments.
Comment 11 Kenneth Åhman 2008-05-12 16:12:38 EDT
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.
Comment 12 Frederic Medery 2008-06-20 10:26:02 EDT
(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 ??
Comment 20 errata-xmlrpc 2008-07-23 09:03:46 EDT
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
Comment 25 David 2010-04-23 17:36:56 EDT
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.
Comment 26 Marcela Mašláňová 2010-04-27 08:11:33 EDT
(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,...
Comment 27 David 2010-04-29 16:21:19 EDT
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?
Comment 28 Stanislav Ochotnicky 2010-04-30 09:36:40 EDT
(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.

Note You need to log in before you can comment on or make changes to this bug.