On Mon, Jan 05, 2026 at 02:23:49PM +1100, Viktor Dukhovni via Postfix-users
wrote:
> And of couse also specific master.cf services may override main.cf
> settings with table references, and the custom tables might again not be
> visible to proxyread, ...
>
> This is a tricky problem: without a robust configuration parser that
> processes both main.cf and master.cf, but also recurses into nested
> tables, ... it may be difficult to handle the general case.
A simpler approach may be to authenticate that requests for replacement
table generation originate from a master(8)-spawned process, by having
the client pass a file-descriptor that it (as root) opened during its
pre-jail initialisation, or just a file descriptor that it inhertied
from master(8) in the first place. The receiving service can check
that it got a descriptor for the expected (root-only-accessible) file.
The file could be one end of a pipe, and not even present "on disk".
If the request is to build a replacement for an indexed file that would
have used a ".db" extension, both the source file and the ".db" file
would have to exist and have matching ownership, and be in a directory
that is not world-writable.
With that, it may be safe enough to allow requests to generate a ".cdb"
or ".lmdb" companion, for any extant ".db" file, when the request is
from an authentic Postfix service.
Admittedly, if a network like smtpd(8) has an RCE vulnerability, it
might now be able to create ".cdb" and ".lmdb" companions to to
extant ".db" files that are were not intended for use with Postfix.
Perhaps that's a bridge too far.
One might therefore limit the files to live in either the Postfix
configuration or queue directories, or else match one of the
proxy_read/write table lists. With that, one can perhaps
reasonably expect to get a good compromise beteen coverage and
compromise containment.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
