Description of problem: When mail delivery_method is configured to use sendmail (standard postfix as installed by RHEL) it generates SELinux violations related to dynflow_executor: $ cat /etc/foreman/email.yaml production: delivery_method: :sendmail $ grep -i seal /var/log/messages Oct 18 20:01:35 li-lc-1578 setroubleshoot: SELinux is preventing /usr/sbin/sendmail.postfix from append access on the file /var/run/foreman/pids/dynflow_executor.output. For complete SELinux messages. run sealert -l 81ed8442-059a-444a-bbf2-1a2b75fabb23 Oct 18 20:01:36 li-lc-1578 setroubleshoot: SELinux is preventing /usr/sbin/sendmail.postfix from append access on the file /var/run/foreman/pids/dynflow_executor.output. For complete SELinux messages. run sealert -l 81ed8442-059a-444a-bbf2-1a2b75fabb23 Oct 18 20:01:43 li-lc-1578 setroubleshoot: SELinux is preventing /usr/sbin/sendmail.postfix from append access on the file /var/run/foreman/pids/dynflow_executor.output. For complete SELinux messages. run sealert -l 81ed8442-059a-444a-bbf2-1a2b75fabb23 Oct 19 09:32:06 li-lc-1578 setroubleshoot: SELinux is preventing /usr/sbin/sendmail.postfix from append access on the file /var/run/foreman/pids/dynflow_executor.output. For complete SELinux messages. run sealert -l 81ed8442-059a-444a-bbf2-1a2b75fabb23 Oct 19 14:58:20 li-lc-1578 setroubleshoot: SELinux is preventing /usr/sbin/sendmail.postfix from append access on the file /var/run/foreman/pids/dynflow_executor.output. For complete SELinux messages. run sealert -l 81ed8442-059a-444a-bbf2-1a2b75fabb23 $ zgrep -i seal /var/log/messages-20151018.gz | grep -c 81ed8442-059a-444a-bbf2-1a2b75fabb23 240 $ sudo sealert -l 81ed8442-059a-444a-bbf2-1a2b75fabb23 SELinux is preventing /usr/sbin/sendmail.postfix from append access on the file /var/run/foreman/pids/dynflow_executor.output. ***** Plugin leaks (86.2 confidence) suggests ****************************** If you want to ignore sendmail.postfix trying to append access the dynflow_executor.output file, because you believe it should not need this access. Then you should report this as a bug. You can generate a local policy module to dontaudit this access. Do # grep /usr/sbin/sendmail.postfix /var/log/audit/audit.log | audit2allow -D -M mypol # semodule -i mypol.pp ***** Plugin catchall (14.7 confidence) suggests *************************** If you believe that sendmail.postfix should be allowed append access on the dynflow_executor.output file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep sendmail /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:system_mail_t:s0 Target Context system_u:object_r:foreman_var_run_t:s0 Target Objects /var/run/foreman/pids/dynflow_executor.output [ file ] Source sendmail Source Path /usr/sbin/sendmail.postfix Port <Unknown> Host li-lc-1578 Source RPM Packages postfix-2.6.6-6.el6_5.x86_64 Target RPM Packages file /var/run/foreman/pids/dynflow_executor.output is not owned by any package Policy RPM selinux-policy-3.7.19-279.el6_7.6.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name li-lc-1578 Platform Linux li-lc-1578 2.6.32-573.7.1.el6.x86_64 #1 SMP Thu Sep 10 13:42:16 EDT 2015 x86_64 x86_64 Alert Count 492 First Seen Tue Oct 6 02:01:37 2015 Last Seen Mon Oct 19 14:58:04 2015 Local ID 81ed8442-059a-444a-bbf2-1a2b75fabb23 Raw Audit Messages type=AVC msg=audit(1445266684.536:1061): avc: denied { append } for pid=20151 comm="sendmail" path="/var/run/foreman/pids/dynflow_executor.output" dev=dm-1 ino=1711405 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:object_r:foreman_var_run_t:s0 tclass=file type=SYSCALL msg=audit(1445266684.536:1061): arch=x86_64 syscall=execve success=yes exit=0 a0=984aa0 a1=983470 a2=983140 a3=38 items=0 ppid=2893 pid=20151 auid=4294967295 uid=495 gid=494 euid=495 suid=495 fsuid=495 egid=494 sgid=494 fsgid=494 tty=(none) ses=4294967295 comm=sendmail exe=/usr/sbin/sendmail.postfix subj=system_u:system_r:system_mail_t:s0 key=(null) Hash: sendmail,system_mail_t,foreman_var_run_t,file,append audit2allow #============= system_mail_t ============== allow system_mail_t foreman_var_run_t:file append; audit2allow -R #============= system_mail_t ============== allow system_mail_t foreman_var_run_t:file append; Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Configure postfix 2. Configure mail with delivery_method sendmail 3. Enable repository errata notifications 4. Sync RedHat repositories Actual results: SELinux violations reported Expected results: No SELinux violations Additional info:
Peter, this looks like harmless bug which we will fix in 6.2. Can you please show me what sendmail tries to append to that file? The issue is in STDERR/STDOUT file handlers, we redirect them in the process into the file, but then when sendmail is spawned and SELinux domain changed, we do not put these handlers back so the child process tries to append there. Most likely there was some problem in delivery and sendmail writes an error to STDERR. Thanks for the report!
Upstream bug component is SELinux
I did a setenforce Permissive and then Sycned a repo with ErrataMail configured. The selinux alert is logged, but the /var/run/foreman/pids/dynflow_executor.output is not updated, see also the stat output: [crash] root@li-lc-1578:~# getenforce Permissive Dec 12 13:03:02 li-lc-1578 setroubleshoot: SELinux is preventing /usr/sbin/sendmail.postfix from append access on the file /var/run/foreman/pids/dynflow_executor.output. For complete SELinux messages. run sealert -l f18505a6-ebc3-4770-8205-106d83deb862 Dec 12 13:03:03 li-lc-1578 setroubleshoot: SELinux is preventing /usr/sbin/sendmail.postfix from getattr access on the file /var/run/foreman/pids/dynflow_executor.output. For complete SELinux messages. run sealert -l 8fa5b509-f57e-4a4f-874b-7b21fd42e281 Dec 12 13:03:03 li-lc-1578 setroubleshoot: SELinux is preventing /usr/sbin/postdrop from append access on the file /var/run/foreman/pids/dynflow_executor.output. For complete SELinux messages. run sealert -l 9883532b-2900-4b27-b4b0-5a552b7cd0cf Dec 12 13:03:03 li-lc-1578 setroubleshoot: SELinux is preventing /usr/sbin/postdrop from getattr access on the file /var/run/foreman/pids/dynflow_executor.output. For complete SELinux messages. run sealert -l 55482ba8-7211-49eb-b09a-0af8f5bf0e8a [crash] root@li-lc-1578:~# cat /var/run/foreman/pids/dynflow_executor.output Starting Rails environment API controllers newer than Apipie cache! Run apipie:cache rake task to regenerate cache. /opt/rh/ruby193/root/usr/share/gems/gems/ffi-1.0.9/lib/ffi/platform.rb:27: Use RbConfig instead of obsolete and deprecated Config. /usr/share/foreman/app/models/concerns/encryptable.rb:5: warning: already initialized constant ENCRYPTION_PREFIX /usr/share/foreman/app/models/concerns/encryptable.rb:5: warning: already initialized constant ENCRYPTION_PREFIX /usr/share/foreman/app/models/concerns/encryptable.rb:5: warning: already initialized constant ENCRYPTION_PREFIX Starting listener Everything ready [crash] root@li-lc-1578:~# stat /var/run/foreman/pids/dynflow_executor.output File: `/var/run/foreman/pids/dynflow_executor.output' Size: 621 Blocks: 8 IO Block: 4096 regular file Device: fd01h/64769d Inode: 1200391 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 494/ foreman) Gid: ( 493/ foreman) Access: 2015-12-12 12:49:40.846866122 +0000 Modify: 2015-12-12 12:15:14.193413296 +0000 Change: 2015-12-12 12:15:14.193413296 +0000 [crash] root@li-lc-1578:~#
Ok thats fine, the apipie:cache is just a warning, not error.
For the record, we are tracking this as low-priority bug as it does not affect anything (IIUC). I have a pending patch in one of our Ruby dependencies to fix the leaked file descriptor: https://github.com/thuehlinger/daemons/pull/43
Patch was accepted upstream in the rubygem daemons, output will be now in syslog rather than leaked descriptor: https://github.com/theforeman/foreman-tasks/pull/234
lzap, is this commet for the correct bug?
Huh, well this is a valid bug, it's not urgent as this is a file descriptor leak. Fixed upstream, we need to wait until they release new version. I am going to close this bug as we track this problem upstream and it will be part of the Satellite future releases.