RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 617472 - logwatch cannot execute sendmail
Summary: logwatch cannot execute sendmail
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy
Version: 6.0
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Miroslav Grepl
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On:
Blocks:
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)

Fixed In Version: selinux-policy-3.7.19-35.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-08-13 10:25:46 UTC
Target Upstream Version:
Embargoed:

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:
/etc/cron.daily/0logwatch:

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):

selinux-policy-3.7.19-33.el6.noarch
logwatch-7.3.6-48.1.el6.noarch

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 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;


Mark,
you can allow it using

# cat > mylogwatch.te << _EOF
policy_module(mylogwatch,1.0)
require{
 type logwatch_mail_t;
 role system_r;
}

role system_r types logwatch_mail_t;
_EOF


# 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_base_mail_template(logwatch)
mta_sendmail_domtrans(logwatch_t, logwatch_mail_t)
role system_r types logwatch_mail_t;
logging_read_all_logs(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

interface(`mta_sendmail_domtrans',`
	gen_require(`
		attribute mta_exec_type;
	')

	files_search_usr($1)
	allow $1 mta_exec_type:lnk_file read_lnk_file_perms;
	corecmd_read_bin_symlinks($1)
	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.