Bug 241067 - crontab should verify a user's access to PAM cron service
Summary: crontab should verify a user's access to PAM cron service
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: vixie-cron   
(Show other bugs)
Version: 4.7
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Marcela Mašláňová
QA Contact: BaseOS QE
Keywords: Reopened, Triaged
: 248459 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2007-05-23 20:38 UTC by Kevin Graham
Modified: 2010-03-19 08:36 UTC (History)
6 users (show)

Fixed In Version: 4.1-83.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 249512 (view as bug list)
Last Closed: 2010-03-18 15:29:59 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Kevin Graham 2007-05-23 20:38:08 UTC
[..Originally covered in Issue Tracker 116438..]

Description of problem:

Presently crond and crontab use completely separate means of authorization. This
can lead to a situation where a user can create or manipulate their crontab that
may not ever be permitted to execute. crontab uses /etc/cron.{allow,deny}
exclusively, and crond uses PAM exclusively.

While we can understand some cases where a user may be permitted to have a
crontab but not edit it (/etc/cron.{deny,allow}), for example a daemon account
whose crontab is manipulated by root, a user who isn't permitted to run a
cronjob shouldn't be able to create one. This "silent" failure inevitably leads
to confusion for both the user and admin.

In our case, we populate access.conf in production to limit the users who may
have crontabs, ie:
    -:ALL EXCEPT root :cron

How reproducible:

Steps to Reproduce:
1. Revoke user 'foo' access via PAM to cron (ie. access.conf)
2. User 'foo' edits crontab.
3. Crontab entries are never executed.
Expected results:

Prior to invoking editor, crontab (and perhaps atq) report:

       You (foo) are not allowed access to cron, crontab
       entries will not be executed.

While a pause-for-acknowledgment would seem to make the most sense, this could
break automated maintenance of crontabs, so perhaps requiring a "-f" flag would
be the safest means.

Additional info:

It'd be great to see documentation updated to emphasize that cron.deny and
cron.allow are really "crontab.deny" and "crontab.allow" and have no effect on
the operation of cron. Calling this out explicitly would hopefully correct a
common misconception.

Comment 1 Marcela Mašláňová 2007-06-20 14:58:37 UTC
I need more information about problem. Could you tell me version of vixie-cron,
crontab, pam and which rhel do you have?

Comment 2 Kevin Graham 2007-06-20 15:04:41 UTC
re comment 1 -- opened this specifically against RHEL4 (so for completeness,
we'll say vixie-cron 4.1-44.EL4 and pam 0.77-66.17), but versions are largely
irrelevant as the same applies to RHEL3 or RHEL5.

Comment 3 Kevin Graham 2007-07-18 13:31:57 UTC
Marcela -- do you require any further details?

Comment 4 Marcela Mašláňová 2007-07-19 07:58:50 UTC
*** Bug 248459 has been marked as a duplicate of this bug. ***

Comment 5 Marcela Mašláňová 2007-07-20 08:30:06 UTC
No, thanks, now I have enough information. 

You're right, the problem is even on RHEL-5, but not the exactly same. I'm
working on fix for both RHEL, it will be available in next update.

Comment 8 Fedora Update System 2007-07-30 17:02:55 UTC
vixie-cron-4.1-83.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.

Comment 9 Marcela Mašláňová 2007-07-31 06:12:19 UTC
Comment #8 is only for Fedora 7. 

This fix should be included in next release.

Comment 10 Fedora Update System 2007-08-24 05:37:47 UTC
vixie-cron-4.1-83.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 11 Marcela Mašláňová 2007-08-24 09:26:59 UTC
Bug wasn't fixed for RHEL-4.7, patch is ready.

Comment 12 RHEL Product and Program Management 2008-02-01 19:08:03 UTC
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. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".

Comment 22 RHEL Product and Program Management 2008-12-05 13:34:22 UTC
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.

Comment 29 Jeremy West 2009-05-19 20:40:21 UTC

*** This bug has been marked as a duplicate of bug 249512 ***

Comment 30 R P Herrold 2009-05-19 20:55:23 UTC
Jeremy West  249512    is not generally visible ... could you please summarize, or clone into an open form that prior bug

Comment 33 Kevin Graham 2010-03-19 02:06:51 UTC
This is CLOSED/WONT but a dupe of 249512? To followup to comment 30, could someone clarify the disposition of that bug?

Comment 34 Radek Vokal 2010-03-19 08:36:07 UTC
The product management and development management agreed that due to significant differences between pam in RHEL4 and RHEL5 and due to RHEL4 state where we are targeting only performance issues and security issues for 4.9. This is still considered for RHEL5 (via the bug you are referencing)

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