On Wed, Jun 18, 2025 at 09:13:25AM +0200, lejeczek via Postfix-users wrote:
> All these SELinux denials were caused by an external tool (part of the HA
> management actually & running on the same box as postfix), a script which
> part is:
>
> sendmail)
> sendmail -t -r "${email_sender}" <<__EOF__
> From: ${email_sender}
> To: ${email_recipient}
> Return-Path: ${email_sender}
> Subject: ${email_subject}
>
> ${email_body}
> __EOF__
It seems the shell uses a pipes rather (say) a temporary file to
implement "here documents", and SELinux, in its infinite wisdom
denies access to the read end of the pipe to the postdrop(1)
process.
> Would somebody care to comment as to whether:
> a) is there anything on postfix's end exclusively, that could be "fixed in"
> to mitigate such a scenario where external tool does "circumvent" mail
> delivery?
There's no circumvention here, reading message input from a pipe is
rather ordinary behaviour. The simplest solution is to turn off
SELinux, or to teach it "new tricks", by configuring it to allow
postdrop to read from a pipe.
On the Postfix end, you could replace /usr/sbin/sendmail with a wrapper:
#! /bin/sh
tmp=$(mktemp -t) || exit 1
cat > "$tmp"
exec < "$tmp"
/bin/rm -f "$tmp"
# Adjust path to real Postfix sendmail as needed
exec /usr/sbin/sendmail.postfix "$@"
Test this first under some other name before replacing
"/usr/sbin/sendmail" and make sure the "execute" bit is
set.
> b) what to "fix" on "external" mail tools' end in order to adhere to
> system's default mail delivery?
See above.
--
Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
