I got a similar problem when trying to run cron as root. It looks like selinux is unable
to get the correct user context of the crond process
crond: (*system*) NULL security context for user ()
crond: CRON (root) ERROR: failed to change SELinux context
crond: CRON (root) ERROR: cannot set security context
The file context of the cron file is set according to default context:
$ ls -lZ /etc/cron.d/testing-cron
-rw-r--r-- root root system_u:object_r:system_cron_spool_t:s0 /etc/cron.d/testing-cron
$ ps -efZ | grep crond
staff_u:system_r:crond_t:s0 root 14922 1 0 00:19 ? 00:00:00
$ /usr/sbin/semanage login -l | egrep "root|system"
root root s0-s0:c0.c1023
system_u system_u s0-s0:c0.c1023
bash-3.1# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5 (Tikanga)
any help is welcome.
----- Ursprüngliche Mail ----
Von: Aleksander Adamowski <aleksander.adamowski.fedora(a)altkom.pl>
Gesendet: Mittwoch, den 28. November 2007, 16:10:58 Uhr
Betreff: Re: RHEL5 + strict policy: Unprivileged user cron - "Unauthorized SELinux
Stephen Smalley pisze:
On Wed, 2007-11-28 at 21:16 +0100, Aleksander Adamowski wrote:
> crond: (apache) Unauthorized SELinux context, but SELinux in
> permissive mode, continuing (cron/apache)
> crond: (apache) NULL security context for user, but SELinux
> permissive mode, continuing ()
Sounds like it just stayed in crond's context since it failed the
and the system was permissive. Naturally, in enforcing mode, it
have not executed the job at all.
crond computes a context for the user's cron job in the usual manner,
then applies a entrypoint permission check between that context and
file context on the crontab file (which gets picked up from a
combination of its creator and the parent directory). If that check
fails, then crond refuses to execute the crontab commands in that
process context. The check is intended to prevent injection of
from one context into another via crontab, unless authorized by
I'd have expected it to try to run the cron job in
user_crond_t:s0 since apache wouldn't have a specific entry in
So it would have wanted the crontab file to have user_cron_spool_t
it, which would have happened if a user_t process created it. If
instead an admin created it and it got sysadm_cron_spool_t or
staff_cron_spool_t, that might explain it. So you could relabel it
allow that permission. First though check the current label on the
Yes, you're right. That was precisely the cause.
I've used "crontab -e -u apache" as root.
The files in /var/spool/cron got sysadm_cron_spool_t type (the full
context was root:object_r:sysadm_cron_spool_t).
After running "fixfiles relabel /var/spool/cron/", the apache crontab
Now cron runs fine and doesn't log anything suspicious.
IMHO crontab should be modified to relabel crontab files that are
using the "-u" option, but this is a question to Dan - should I file a
new bug to bugzilla.redhat.com
ICQ UIN: 19780575
fedora-selinux-list mailing list
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de