[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
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]
