On Mon, 2006-06-19 at 16:22 +0200, Paul J Stevens wrote: > Geo Carncross wrote: > > > So what you're telling me is that you think only developers of dbmail > > should be weighing in on the subject of dbmail's security? > > That would be the death of dbmail. > > I'm no security expert at all, and afaik neither is Aaron. I'm just a > guy who ran across dbmail a couple of years ago, liked it, but found it > lacking in terms of performance, scalability, reliability and code > quality. I've since invested deeply in addressing those issues without > doing a complete rewrite, and have gained some compentency in C along > the way which I didn't have before.
Since the whole %sdbmail_* thing went in and a "table prefix" was afforded, I'm thinking it'd be a relatively slim set of changes to give each mailbox it's own table(s) - just set the prefixes at login time, and the value would be enormous: A complete audit of dbmail wouldn't be necessary to provide hard/fast truths on DBMail's security. Maybe the OpenBSD people can audit something big like DBMail (as they did with Sendmail)- but I cannot. I _can_ help with privilege separation as this is what I'm currently doing. My reasoning is pretty simple- I just ask myself what is worse: * Small possibility of user damaging their own mailbox, and any other mailbox they have write access to, ZERO possibility of damaging anyone elses' mailbox, ZERO possibility of stealing email from other users, and ZERO possibility of gaining a machine account, _OR_ * Small possibility of damaging every mailbox, small possibility of stealing email from other users, and a small possibility of gaining a machine account (with perhaps the ability to escalate that later). I don't know as this is a 2.2 thing, or even a 2.4 thing, but it might be useful to make it a 3.0 thing, because it'd pretty much make the possibility of a certain special kind of headache just _go_away_. I like solutions like that. We'd also get some other benefits on the cheap: * Removal of Access control code (moved into SQL) * Easy to chroot and drop privileges * Easy to set per-user resource limits Not to mention the fact that only the privilege separating code needs to be audited carefully, and not all of dbmail. -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/