On Thu, Aug 17, 2006 at 10:30:07AM -0600, Jesse Norell wrote: > > On Thu, August 17, 2006 09:29, Lars Kneschke wrote: > > [EMAIL PROTECTED] schrieb: > >>> Yes. That's my main concern. > >>> > >> > >>It's not all that different to imapd having access to the whole db. > >>Unless you have seperate DB's per user you can't have that layer. > >>At some point you have to trust something ;-> > > > > A webbased application has stored the database connection string in > > cleartext somewhere on the webserver. If you hack the webserver and get > > the > > sql connection setting you have access to the whole (imap)database. That's > > really bad. > > > > If you access the imap server over the imap protocol, you need to have a > > username/password. And if you get this somehow, you can still access only > > one imap box(ignoring acl). > > But if you hack the imap server, you again have the username/password > for the dbmail database, so same situation. I'd think in general it's None of that is (automatically) true, at least for PostgreSQL. From a connection standpoint, there are a number of ways to set things up such that only the machine running the IMAP daemon can connect (and connect only as the IMAP user), and I can think of at least 2 ways that don't involve storing any passwords in the IMAP code (in fact, one way means not using passwords at all).
> > That's the main difference and my main concern. > > I'd be interested in what you come up with for a solution here. I've > put just a little thought to this same scenario in the past, and came up > with wanting to stick a proxy in between the client and sql server. > Either something that can police the specific queries made or use some > custom protocol to generate the query on the proxy (eg. client sends > "folderlist [EMAIL PROTECTED]" and the proxy runs the sql for that and returns > the results). The former would probably be easier to impliment, the > latter would give more flexibility (eg. you could stick the session id > in there, too, so the proxy can verify the owner of the session against > a query to look up that account's mail, etc.). Rather than create an entire extra server, why not use stored procedures? If every access method to the database is a stored procedure, you can remove all access to the base tables. That means that the stored procedures can then do whatever security checking is desired; perhaps passing each one a username and password, or an authentication token. The procedures would then limit access to only that user's information. Of course, this doesn't mean that the system is hack-proof, but there's a number of ways to greatly improve security without resorting to one database per user. -- Jim C. Nasby, Database Architect [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
