Date: 2 Apr 2002 00:21:08 -0000 From: "D. J. Bernstein" <djb@cr.yp.to> To: chat@freebsd.org Subject: Re: qmail (Was: Maintaining Access Control Lists ) Message-ID: <20020402002108.4432.qmail@cr.yp.to>
next in thread | raw e-mail | index | archive | help
rsidd@online.fr writes: > The only one I'm aware of, which Wietse pointed out years ago and > continues to harp on, is the memory exhaustion thing, which in Dan's > opinion is the job of the operating system and not the MTA Yes, I think it's the OS's job. The OS itself agrees with me. The UNIX kernel, with the cooperation of the standard shells, gives the sysadmin configurable, easy-to-use per-process memory rlimits. Reinevnting the same feature by adding separate code to every program to impose artificial limits on every dynamically allocated structure for network data is remarkably bad engineering. Last November, years after I made these comments on my web pages, someone discovered that Venema had forgotten to put an artificial limit on Postfix's dynamically allocated session log. Consequently an attacker could trivially convince Postfix's smtpd to use all available memory. Did Venema scream that Postfix had ``A BUG'' that ``made'' systems ``vulnerable to memory exhaustion attacks''? Did he post an ``exploit'' for this Postfix ``BUG''? Did he try to have Postfix entries added to vulnerability databases? Did he admit that his approach was vastly more complicated and error-prone than system resource limits? No, he didn't. I spend quite a bit of time analyzing system failures and investigating how they could have been prevented by better programming practices--- preferably practices that also save time for the programmers. Frankly, in this case, there's no contest. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020402002108.4432.qmail>