On Wed, 2006-06-21 at 16:53 -0500, Jim C. Nasby wrote: > One possibility would be to have the database handle all authentication > and requests via stored procs, and restricting the dbmail database > account to only having access to those stored procs. Or you could use > per-user authentication to the database, as someone else suggested. > Whether either step is worth the trouble...
These procedures- if only abstract sqlish versions of IMAP commands, are powerful enough to steal and destroy any users email. If the procedures also did access control (e.g. the first parameter was a session token, or a user/password pair), then it would only move the problem- these procedures would need to be as bullet-proof as DBMail needs to be. Of course, SQLite lives in-core, so it can't offer any security there. Not that I'm saying stored procedures aren't a good idea- they are, and could probably simplify a lot of things in the long run, unfortunately, I can't see them generally adding any security. > Of course, it goes without saying that DBMail should be coded to reduce > the likelyhood of any possibility of an attack. I'm suggesting a further extension of that: DBMail should be coded to eliminate the possibility of certain attacks succeeding: * unauthorized theft of mail * unauthorized destruction of mail Eliminating other attacks (denial-of-service, password cracking, unauthorized network use, unauthorized filesystem access, etc) is really a lot more easily handled _outside_ DBMail. -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/