On February 18, 2026 8:05:58 AM GMT+02:00, Martin McClure via dovecot <[email protected]> wrote: >Thanks, Ralph. > >OK, that makes sense. Dovecot reads the config file (not a bug) and if it sees >the name of the ssl key_file it tries to read /that/ file (yeah, that sounds >very much like a bug) and when it can't it bails. It should only try to read >the cert/key files if it is going to need to use them. > >And wrapping the cert/key filenames in a config file that is itself unreadable >is evil and clever and, well, useful in this case. > >Regards, > >-Martin > > > On 2/17/26 6:33 PM, Ralph Seichter via dovecot wrote: >> * Martin McClure via dovecot: >> >>> Is this expected behavior in 2.4, or is it considered a bug? >> I'm not Aki, but since I ran into the same issue a while back: I'd like >> to repeat that I do consider this to be a bug. It also affects doveadm >> use, for example. >> >> The problem occurs when a non-root process triggers evaluation of the >> Dovecot config and is unable to read the TLS key files. Protecting these >> files is of course important, and some random user invoking doveadm in >> their command shell should have no reason to access sensitive files. >> IMO, Dovecot should not even attempt to read TLS related files in this >> case. They are not needed at this time. >> >>> If it's expected behavior, why does this workaround work? >> The "!include_try foo.conf" succeeds when run as root, e.g. during >> Dovecot startup, but fails silently for non-root owned processes. That's >> why it works as a workaround. >> >> -Ralph >> _______________________________________________ >> dovecot mailing list [email protected] >> To unsubscribe send an email [email protected] This is indeed a bug. It should get fixed in next release.
Aki _______________________________________________ dovecot mailing list -- [email protected] To unsubscribe send an email to [email protected]
