I did a FC2 install 'everything' and that seems to have turned on mailman cron entries. Unfortuneately, the one that runs /var/mailman/cron/gate_news (every 5 minutes!) fails and sends email to email with the report:
Subject: Cron <mailman@dell> /usr/bin/python -S /var/mailman/cron/gate_news
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/var/mailman>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=mailman>
execl: couldn't exec `/bin/sh' execl: Permission denied
The equivalent avc message is:
May 21 12:00:00 dell kernel: audit(1085166000.890:0): avc: denied { transition } for pid=7796 exe=/usr/sbin/crond path=/bin/bash dev=hdb3 ino=376840 scontext=system_u:system_r:crond_t tcontext=user_u:sysadm_r:sysadm_t tclass=process
The appropriate entry in crond.te (I think) is: can_exec(crond_t, shell_exec_t)
The labels for /bin/bash and /bin/sh are as follows (from a clean FC2 install):
-rwxr-xr-x+ root root system_u:object_r:shell_exec_t bash
lrwxrwxrwx+ root root system_u:object_r:bin_t sh -> bash
Is the label for /bin/sh causing this to fail?
tom
------------------------------------------------------------------------
* /From/: Daniel J Walsh <dwalsh redhat com>
* /To/: "Fedora SELinux support list for users & developers."
<fedora-selinux-list redhat com>
* /Subject/: Re: restorecon vs. setfiles
* /Date/: Wed, 19 May 2004 15:17:50 -0400------------------------------------------------------------------------ Stephen Smalley wrote:
On Tue, 2004-05-18 at 23:07, Daniel J Walsh wrote:
Looks like a bug in matchpathcon (Which is used buy restorecon). It is returning the wrong security context. I will send this to stephen. Basically looks like it is ignoring file type.
matchpathcon takes a pathname and optional file mode as input parameters for matching against the file contexts configuration. It doesn't attempt to stat the file itself to obtain the mode because it is sometimes used by programs that are creating new files (e.g. udev) and want to know the context for the file they are about to create, so it requires the caller to provide the mode. restorecon currently passes 0 as the mode, so no mode matching is performed.
So this is a bug in restorecon; it needs to be changed to stat the file and provide the mode.
policycoreutils-1.12-2 has two fixes for restorecon, it handles the symbolic link problem and ignores <<none>>.
Dan
