On Mon, Sep 21, 2026 at 6:48 PM Wietse Venema via Postfix-users <[email protected]> wrote: > > [non-set-gid postdrop client talking to world-writable socket] > > > It is not limited by the number of processes that a hostile user can run. > > > > That's not correct, since you would have a real rate limit, which the > > admin can set depending on his needs and does not depend on the number > > of a processes, which a user needs to be able to run to do his work. > > The existing implementation relies on a client-side PER-USER process > limit, to limit concurrent requests. > > You are proposing a world-writable socket with a server-side > PER-SYSTEM connection limit, meaning that one user can deny service > to everyone.
No, as I wrote, systemd has a per user limit for concurrent access and per time. I didn't configure that in my PoC because I didn't expect anyone would actually use "ulimit -u" for rate limits. If configured that way, one user cannot deny service to everyone. > > Did you look at my PoC patch? > > > > No special code for systemd is necessary; just run the protocol over a > > socket instead of a pipe. There is no real code change except the ACL > > check. That should be moved to the server. > > That's 150 lines of non-reusable C code to replace a sendmail<=>postdrop > pipe with a UNIX-domain socket. > > - The systemd template runs postdrop with the 'postfix:postdrop' > privileges for policy enforcement and low-level input validation. > That should be a non-postfix UID. The postdrop code was not implemented > to run with Postfix core privileges. Creating additional users is quite simple and no problem. > - Error reporting needs to be changed: it's no good when postdrop > running as a daemon reports problems to stderr. But, not all the > world is Linux, so that stderr logging is still needed. postdrop should never run as "daemon", it should run as a systemd socket activated service in my scenario. In that case, you can tell systemd where to redirect stdout or stderr. No need to complicate the code with own functions. For the rest I need much more time to familiarize myself with the postfix code. Thorsten > Unfortunately, I don't think that the 150-line postdrop solution > will generalize to the other client programs. > > The other client programs, postlog and postqueue, will need a > systemd-managed socket, too. They will also need admission control, > input validation, and error reporting. > > I expect that it takes less than 150 lines of non-reusable code > split a postlog or postqueue client program into 1) a small user-facing > front-end portion that talks over a systemd-managed UNIX-domain > socket to 2) a larger back-end portion that talks to the Postfix > core. The back-end portion enforces UID-based admission control and > low-level input validation. In some cases, such as 'postqueue -p', > copy overhead can be eliminated by passing the core connection from > the back-end portion to the front-end portion. > > Most of that new code should be a reusable library function. > > If we can do that with postqueue and postlog, then we can do the > same thing with postdrop. One consistent architecture instead of a > different sets of custom code for each different client. > > > But of course, you can also create yet another application, which > gets > > Postfix doesn't need more applications - the existing three suffice. > > Except for the absence of a PER-USER concurrency limit, "now new > privs" can be implemented with one dedicated UID, one systemd > configuration per client (postlog, postdrop, postqueue) socket and > program, and a new client command-line option to activate the > back-end half of a client program. For backwards compatibility, the > default mode should be 'front end'. > > Wietse > _______________________________________________ > Postfix-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] -- Thorsten Kukuk, Distinguished Engineer, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Geschäftsführer: Stefan Gaiser, Jochen Jaser, Abhinav Puri (HRB 36809, AG Nürnberg) _______________________________________________ Postfix-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
