dovecot - Jan 2018 - Updated Dovecot 2.3.0 now getting 2 strange log errors

On 2018-01-02 17:21, tony wrote:
> On 2018-01-02 16:37, tony wrote:
>> On 2018-01-01 17:26, Peter wrote:
>>> On 02/01/18 14:07, Stephan Bosch wrote:
>>>>> I can see 21:21:38 is when the below errors showed up with
the
>>>>> above
>>>>> 21:21:38 timestamps:
>>>>> 
>>>>> Dec 29 21:21:38
>>>>> lmtp(recipient at
domain.net)<17187><UA2fMEQiR1ojQwAAUXb6+w>: Error:
>>>>> program `/usr/sbin/sendmail' was forcibly terminated
with signal 15
>>>>> Dec 29 21:21:38
>>>>> lmtp(recipient at
domain.net)<17187><UA2fMEQiR1ojQwAAUXb6+w>: Error:
>>>>> sieve: msgid=<470c210f-bd19-f63f-45ed-bfef59322be9 at
domain.email>:
>>>>> failed to send vacation response to sender at domain.email:
<Failed to
>>>>> execute sendmail> (temporary error)
>>>>> Dec 29 21:21:38 lmtp: Error: postdrop: warning:
mail_queue_enter:
>>>>> create file maildrop/868503.17337: Permission denied
>>>>> 
>>>>> It still isn't really clear to me why this is going on.
>>>> 
>>>> I am wondering what that sendmail process is doing.
>>>> 
>>>> As you can see, Dovecot waits for it to finish for 30 seconds 
>>>> (override
>>>> with submission_timeout setting).
>>>> 
>>>> Can you try invoking sendmail manually from command line? Does
it
>>>> work?
>>>> Is it hanging for more than 30s?
>>> 
>>> I think the real error here is the postdrop one (sendmail is a 
>>> wrapper
>>> around postdrop).  It's a permission denied error which leads
me to
>>> believe it may be an selinux (or similar) issue.  I wouldn't be
>>> surprised if sendmail works from the command line but fails when
>>> executed from sieve because selinux has it blocked for sieve.
>>> 
>>> If you're running selinux or apparmour or similar, check your
logs
>>> for
>>> that (audit log for selinux) and look for denials.  You cna also
try
>>> setting selinux to permissive and trying the operation (setenforce 
>>> 0).
>>> 
>>> 
>>> Peter
>> 
>>> I am wondering what that sendmail process is doing.
>>> 
>>> As you can see, Dovecot waits for it to finish for 30 seconds 
>>> (override
>>> with submission_timeout setting).
>>> 
>>> Can you try invoking sendmail manually from command line? Does it 
>>> work?
>>> Is it hanging for more than 30s?
>>> 
>>> Regards,
>>> 
>>> Stephan.
>> 
>> Thanks for the responses. Running sendmail from the command line is
>> successful, which strikes me as odd. So it is only failing when
>> sendmail is invoked from sieve, but I don't yet understand why. I
>> haven't made any recent significant changes to the mail
environment. I
>> haven't updated from postfix 3.2.4-2 since 12-16-17 when my
>> distribution released the packaged updated, but I didn't notice the
>> issue at that time until around 12-27 when I started getting emails
>> about the reported permission denied error and sendmail timeout.
> 
> Apologies for sending too early. I meant to hit save and not sent. I
> wanted to point out that I am not using SELinux or AppArmor. The hosts
> just use some iptables rules, but traffic is permitted to and from
> these hosts, so I don't think that is the issue. There are several
> places that talk about correcting permissions, but when I verify the
> permissions on /var/lib/postfix everything is as it should be.
> 
> postfix set-permissions
> postfix check
> 
> The above results in no output reporting any problems. I enabled sieve
> tracing but did not see anything that stood out apart from the usual
> reported errors. If I invoke sendmail from the vmail user I am able to
> send no problem. It doesn't make sense why sieve in general not
> related to Vacation auto-replies works fine, but auto-replies do not.
> 
> -
> TC
I downgraded dovecot to 2.2.33.2 and pigeonhole 0.4.21 and can confirm 
the reported problem does not exist with "permission denied" and 
sendmail getting hung up/timing out.

-
Cheers,
TC

On 03.01.2018 18:14, Tony wrote:
> I downgraded dovecot to 2.2.33.2 and pigeonhole 0.4.21 and can confirm 
> the reported problem does not exist with "permission denied" and 
> sendmail getting hung up/timing out.
The issue is that sendmail/maildrop/postdrop uses setgid to change to
the maildrop group (`stat $(which postdrop)`) and the
NoNewPrivileges=true setting in the service file explicitly disables
this (look in man systemd.exec). This settings appears to be new in 2.3[1].

What is somewhat infuriating is that this behaviour change is not
mentioned in the release notes/upgrade notes and the commit that
introduces the change changes multiple things and it doesn't explain why
things are changed. I'm happy to see service files that try to improve
security in an upstream repository though.

Does pigeonhole have any options to configure how mail is send when
using "redirect :copy" (possibly more commands, this is just what
triggered it here)? If not, support for injecting mail back via smtp
would be lovely. I'd like to reenable NoNewPrivileges at some point.

[1]
https://github.com/dovecot/core/commit/563c1e3b45bbb69bc67b75ff7a899699bea18e88#diff-5bbec0a0006d92d441b5c8fa72690f95

Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 858 bytes
Desc: OpenPGP digital signature
URL:
<https://dovecot.org/pipermail/dovecot/attachments/20180106/1bb35a54/attachment.sig>

Op 1/6/2018 om 7:42 PM schreef Florian Pritz:
> On 03.01.2018 18:14, Tony wrote:
>> I downgraded dovecot to 2.2.33.2 and pigeonhole 0.4.21 and can confirm 
>> the reported problem does not exist with "permission denied"
and
>> sendmail getting hung up/timing out.
> The issue is that sendmail/maildrop/postdrop uses setgid to change to
> the maildrop group (`stat $(which postdrop)`) and the
> NoNewPrivileges=true setting in the service file explicitly disables
> this (look in man systemd.exec). This settings appears to be new in 2.3[1].
>
> What is somewhat infuriating is that this behaviour change is not
> mentioned in the release notes/upgrade notes and the commit that
> introduces the change changes multiple things and it doesn't explain
why
> things are changed. I'm happy to see service files that try to improve
> security in an upstream repository though.
>
> Does pigeonhole have any options to configure how mail is send when
> using "redirect :copy" (possibly more commands, this is just what
> triggered it here)? If not, support for injecting mail back via smtp
> would be lovely. I'd like to reenable NoNewPrivileges at some point.
>
> [1]
>
https://github.com/dovecot/core/commit/563c1e3b45bbb69bc67b75ff7a899699bea18e88#diff-5bbec0a0006d92d441b5c8fa72690f
The submission_host setting should do what you need:

https://github.com/dovecot/core/blob/master/doc/example-config/conf.d/15-lda.conf#L20

Regards,

Stephan.