Bug 207433 - LTC27232-LSPP - cron doesn't run jobs in enforcing mode
LTC27232-LSPP - cron doesn't run jobs in enforcing mode
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: vixie-cron (Show other bugs)
All Linux
high Severity high
: ---
: ---
Assigned To: Marcela Mašláňová
Brock Organ
: Reopened
: 219432 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2006-09-20 21:50 EDT by Issue Tracker
Modified: 2007-11-30 17:07 EST (History)
11 users (show)

See Also:
Fixed In Version: RC
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-02-07 19:13:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
console.log (40.62 KB, text/plain)
2006-10-24 17:51 EDT, Archana K. Raghavan
no flags Details
Patch to add the MLS_LEVEL option to cron (9.34 KB, patch)
2006-12-14 12:08 EST, James Antill
no flags Details | Diff

  None (edit)
Description Issue Tracker 2006-09-20 21:50:13 EDT
Escalated to Bugzilla from IssueTracker
Comment 8 RHEL Product and Program Management 2006-09-21 18:17:09 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux release.  Product Management has requested further review
of this request by Red Hat Engineering.  This request is not yet committed for
inclusion in release.
Comment 12 Marcela Mašláňová 2006-10-02 12:33:42 EDT
It looks like problem of selinux-policy-mls.
Comment 13 Daniel Walsh 2006-10-02 15:13:57 EDT
Fixed in selinux-policy-2.3.17-2
Comment 15 Daniel Walsh 2006-10-20 09:23:39 EDT
I need more information than just crond is not working?   What is not working? 
What AVC messages are you seeing?  Is this on an MLS Machine that it is broken?
Comment 18 Daniel Walsh 2006-10-23 16:24:37 EDT
There is a new policy that would allow writing to /tmp by a cron job on 

Also the way to get this to work currently is 

# crontab -u ealuser -l
* * * * *     touch /tmp/cronjob 

So you need to specify XYZ_crond_t instead of XYZ_t.

The reason for this is selinux policy currently does not allow direct transition
to XYZ_t
Comment 22 Daniel Walsh 2006-10-24 08:24:43 EDT
The bugs reported above are much more serious.  At this point you should not be
booting in permissive mode.  Please clear your log file, reboot in permissive mode 
login and send me the log file.    Also attempt the cron job and send the log
file.  I need to see the avc messages.
Comment 23 Klaus Weidner 2006-10-24 10:25:15 EDT
The sshd login problems may be related to LTC bug #28315 / RH issue tracker
#104436 (sshd segfaults when logging in). Try removing "require_auditd" from the
/etc/pam.d/sshd pam_loginuid line, or disable that line completely.
Comment 24 Klaus Weidner 2006-10-24 11:21:53 EDT
please disregard my previous comment - the sshd / pam_loginuid segfault also
happens in permissive mode so this is unlikely to be related.
Comment 37 Archana K. Raghavan 2006-10-24 17:51:25 EDT
Created attachment 139277 [details]
Comment 40 Daniel Walsh 2006-10-25 11:49:52 EDT
Looking at your log file and running it through audit2allow I find
allow getty_t var_log_t:file { lock write };
allow local_login_t var_log_t:file lock;
Which is caused by a mislabeled /var/run/wtmp
# restorecon -r -v /var/run/wtmp
Does this get mislabeled on ever reboot?

allow local_login_t var_log_t:dir write;
allow local_login_t var_log_t:dir add_name;
allow local_login_t var_log_t:file { create getattr read write };
allow newrole_t var_log_t:file { getattr read write };
These are caused by a mislabeled /var/run/tallylog
Updated pam package should cause this to get labled correctly on install.  I
believe this is what is causing your login failure.
# restorecon -r -v /var/run/tallylog

allow initrc_t var_t:file { setattr write };
This is an init script trying to write to a localtime file labeled var_t?  I
have no idea what this file is unless you have a mislabeled /etc/localtime?

allow secadm_t var_log_t:dir { add_name remove_name write };
allow secadm_t var_log_t:file { create setattr unlink write };
These are valid since you seem to have written to a temp file in /var/run with
dmesg while logged in as secadm.  Not allowed

allow secadm_ssh_t sysadm_home_dir_t:dir search;
allow secadm_ssh_t sysadm_home_ssh_t:dir { getattr search };
allow secadm_ssh_t sysadm_home_ssh_t:file { append getattr read };
These are caused by running ssh while logged in as secadm_t on the root
directory.  I am not sure if the proper fix to this is to disallow ssh as
secadm?  Basically ssh tries to write to the /root/.ssh directory, which is not

allow sysadm_crond_t nscd_var_run_t:dir search;
Added this to policy 2.4.1-4

allow sysadm_crond_t staff_home_dir_t:dir { getattr search };
This is a tough one to prevent since you changes the context of the crond daemon
to sysadm_crond and it tries to look at its homedir.
Comment 43 Daniel Walsh 2006-10-27 14:15:35 EDT
We are working in the mailing list on a new design of how cron should work in an
MLS environment.

Reassigning this bug to vixie-cron.
Comment 45 Marcela Mašláňová 2006-10-31 08:48:14 EST
We're discusing, how could cron work with MLS.
Comment 49 Irina Boverman 2006-12-05 14:18:43 EST
IBM asked to raise bug's severity and priority, it is blocking test efforts.
Please post an update.
Comment 50 Pete Graner 2006-12-13 22:15:30 EST
any idea on when this will be fixed? I need to give PM an answer to they can
target it to a RC candidate.
Comment 51 James Antill 2006-12-14 12:06:59 EST
*** Bug 219432 has been marked as a duplicate of this bug. ***
Comment 52 James Antill 2006-12-14 12:08:49 EST
Created attachment 143660 [details]
Patch to add the MLS_LEVEL option to cron

 Import of patch from 219432, this should fix the bug and allow MLS selection
for crontabs.
Comment 53 Steve Grubb 2006-12-14 14:02:37 EST
vixie-cron-4.1-65.el5 was built to solve this problem.
Comment 54 Klaus Heinrich Kiwi 2006-12-14 14:56:27 EST
Is there anywhere where we can download and test, so we can close this bug asap
(3-month anniversary soon)

Also: any tips on how to use this? From what I've seen, looks like we can only
specify a different mls range, not the hole context - was the documentation also
Comment 55 Daniel Walsh 2006-12-14 15:50:02 EST
Updated package is up on 


You need to update selinux-policy also.

Make sure you have an SELinux user mapping for system_u

semanage login -l | grep system_u

If not you will need to add one, best way to do this is to edit 

And copy that to /etc/selinux/mls

Comment 60 RHEL Product and Program Management 2006-12-22 19:22:39 EST
A package has been built which should help the problem described in 
this bug report. This report is therefore being closed with a resolution 
of CURRENTRELEASE. You may reopen this bug report if the solution does 
not work for you.
Comment 61 Archana K. Raghavan 2006-12-25 11:02:00 EST
Bringing in the last 3 comments from IBM and re-opening based on that:
Send this event to Bugzilla ID:  (Sent to 207433 on 12-18-2006 12:58pm)
----- Additional Comments From gcwilson@us.ibm.com  2006-12-15 17:33 EDT -------
Camilo and Klaus, I think Dan Walsh is discussing this on IRC right now. So I
believe it is still broken. Would you please make a statement in this bug as to
whether or not cron is broken for LSPP? 
  Send this event to Bugzilla ID:  (Sent to 207433 on 12-18-2006 12:58pm)
----- Additional Comments From toml@us.ibm.com  2006-12-18 10:17 EDT -------
Cron is part of the TOE for the LSPP certificaiton and must be working properly
in order to pass the LSPP certification and provide needed functionality to the
LSPP certified system.  Increased functionality within the LSPP system makes it
a more competitive system. 
end this event to Bugzilla ID:  (Sent to 207433 on 12-20-2006 03:08pm)
----- Additional Comments From toml@us.ibm.com  2006-12-20 09:03 EDT -------
Further explanation of business impact:

This will affect all platforms on which RHEL5 is supported.  Expanding on the
previous statement, the cron functionality will create a more functional LSPP
certified system.  Having a more functional system increases the competitiveness
against other LSPP certified systems.  This gives the opportunity for new Red
Hat sales/seats within the government, financial services sector and any other
market segment that requires an LSPP certified system. 
  Send this event to Bugzilla ID:  (Sent to 207433 on 12-20-2006 11:07pm)

          What    |Removed                     |Added
            Status|FIXEDAWAITINGTEST           |TESTED

------- Additional Comments From camiloyc@br.ibm.com  2006-12-20 19:59 EDT -------
Cron is working properly.
/etc/pam.d/crond should have this line:
session    required   pam_namespace.so DEBUG debug

crontab -e on a staff_u user looks like
* * * * * pwd; id > ~/crontest

bash-3.1$ cat crontest
uid=500(ealuser) gid=500(ealuser) groups=10(wheel),500(ealuser)

cron is not able to create a polyinstantiated directory if it not exists. The
error message is:
c 20 17:35:02 rhel5lspp crond[1890]: Cannot make/remove an entry for the
specified session
Dec 20 17:35:02 rhel5lspp crond[1890]: CRON (ealuser) ERROR: failed to open PAM
security session: Success
Dec 20 17:35:02 rhel5lspp crond[1890]: CRON (ealuser) ERROR: cannot set security

If I do a newrole -l <level> before add a task on crontab (creating
automatically home polyinstantiated), cron works fine. I don't know if it is an
error, but I think that should be explained in manpage (I spend much time to
discovery it.)

Another issue that is a potential bug is the fact that I can submit tasks in
crontab only with SystemLow user level. Here are the lines indicating what happened:

"crontab.XXXXGVTldj" 2L, 50C written
crontab: installing new crontab
cron/tmp.XXXXcUk2i2: Permission denied
crontab: edits left in /tmp/crontab.XXXXGVTldj
bash-3.1$ id -Z
bash-3.1$ crontab -l
no crontab for ealuser

Is it a bug?

Comment 62 Daniel Walsh 2007-01-02 09:57:22 EST
This should be fixed in vixie-cron-4.1-66.1.el5
Comment 63 Issue Tracker 2007-01-11 13:47:49 EST
IBM, Snapshot 6 contains vixie-cron-4.1-66.1.el5.src.rpm, please test and
provide feedback on whether this issue is fixed.

This event sent from IssueTracker by John Jarvis 
 issue 102020
Comment 64 Marcela Mašláňová 2007-01-12 10:17:57 EST
Bug is related to #220907. It should work now.
I'll fix the cron man pages.
Comment 66 RHEL Product and Program Management 2007-02-07 19:13:27 EST
A package has been built which should help the problem described in 
this bug report. This report is therefore being closed with a resolution 
of CURRENTRELEASE. You may reopen this bug report if the solution does 
not work for you.

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