Bug 617472 - logwatch cannot execute sendmail
Summary: logwatch cannot execute sendmail
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy
Version: 6.0
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Miroslav Grepl
QA Contact: Milos Malik
Keywords: RHELNAK
Depends On:
TreeView+ depends on / blocked
Reported: 2010-07-23 07:26 UTC by Mark Wielaard
Modified: 2010-08-13 10:25 UTC (History)
5 users (show)

Clone Of:
Last Closed: 2010-08-13 10:25:46 UTC

Attachments (Terms of Use)

Description Mark Wielaard 2010-07-23 07:26:47 UTC
Description of problem:

When logwatch runs it fails to send email:

Can't exec "sendmail": Permission denied at /usr/sbin/logwatch line 1032, <TESTFILE> line 2.
Can't execute sendmail -t: Permission denied

The following is in /var/log/messages:
Jul 23 03:30:02 springer kernel: type=1401 audit(1279848602.964:43711): security
_compute_sid:  invalid context system_u:system_r:logwatch_mail_t:s0-s0:c0.c1023 
for scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:objec
t_r:sendmail_exec_t:s0 tclass=process

Version-Release number of selected component (if applicable):


How reproducible:

It happened once, tonight.

Steps to Reproduce:
1. install logwatch
2. wait till the daily run
Actual results:

Getting a cron failure email

Expected results:

Getting a logwatch email

Comment 2 RHEL Product and Program Management 2010-07-23 07:57:35 UTC
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

Comment 3 Miroslav Grepl 2010-07-23 10:34:43 UTC
We are missing role statement

role system_r types logwatch_mail_t;

you can allow it using

# cat > mylogwatch.te << _EOF
 type logwatch_mail_t;
 role system_r;

role system_r types logwatch_mail_t;

# make -f /usr/share/selinux/devel/Makefile
# semodule -i mylogwatch.pp

Comment 4 Daniel Walsh 2010-07-23 10:37:02 UTC
Miroslav you need these lines in logwatch.te

mta_sendmail_domtrans(logwatch_t, logwatch_mail_t)
role system_r types logwatch_mail_t;
manage_files_pattern(logwatch_mail_t, logwatch_tmp_t, logwatch_tmp_t)

This is definitely a blocker.

Comment 5 Daniel Walsh 2010-07-23 10:37:54 UTC
Miroslav, also make sure this change is in mta.if

		attribute mta_exec_type;

	allow $1 mta_exec_type:lnk_file read_lnk_file_perms;
	domtrans_pattern($1, mta_exec_type, $2)

Comment 6 Miroslav Grepl 2010-07-23 14:30:53 UTC
Fixed in selinux-policy-3.7.19-34.el6.noarch

Comment 7 Jay Turner 2010-07-28 10:41:02 UTC
Even after installing selinux-policy-3.7.19-34.el6 and forcing a relabel, I'm getting the following during the anacron logwatch runs:

sendmail: fatal: chdir /var/spool/postfix: Permission denied

This is made all the more interesting by the fact I cannot seem to reproduce this by calling anacron (or even run-parts) directly.  The permission problem appears to only occur during the scheduled anacron runs.  Flipping back to Assigned.

Comment 8 Daniel Walsh 2010-07-28 14:15:19 UTC
Jay what AVC's are you seeing?

Comment 9 Jay Turner 2010-07-28 18:41:08 UTC
Oddly enough, nothing!.  There's nothing in syslog, nothing in the audit.log, nothing anywhere to explain why this is failing.  Made all the more odd by the fact I'm able to run this script manually without fail.  I cannot put my finger on what is happening in the anacron run that leads to the permission denial.

Comment 10 Daniel Walsh 2010-07-28 19:12:56 UTC
Miroslav should have a fix for this soon.

Comment 11 Jay Turner 2010-07-30 13:19:29 UTC
Any progress here?  I'm still hitting this issue and appears people are hitting this with F13 as well (https://bugzilla.redhat.com/show_bug.cgi?id=617790)

Comment 13 Miroslav Grepl 2010-08-02 15:27:27 UTC
Fixed in selinux-policy-3.7.19-35.el6.noarch.

Comment 14 Jay Turner 2010-08-02 19:12:58 UTC
logwatch appears to be performing well with -35.el6.  Moving to verified and will continue to watch the system for proper behavior.

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