mailman, cron, /bin/sh (more on Re: restorecon vs. setfiles???)
Tom London
selinux at comcast.net
Fri May 21 20:30:37 UTC 2004
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 at 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
More information about the fedora-selinux-list
mailing list