Wietse Venema via Postfix-users: > [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. > > > 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. > > - 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. > > 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 [to] > split a postlog or postqueue client program into 1) a small user-facing > front-end portion that talks over a systemd-managed UNIX-domain
That is an internal split based on a new command-line option. With the option present, it runs in systemd mode; otherwise, as client. > 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] > _______________________________________________ Postfix-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
