On Thu, Jun 15, 2006 at 04:04:55PM -0400, Geo Carncross wrote: > On Thu, 2006-06-15 at 15:01 -0500, Jim Nasby wrote: > > On Jun 15, 2006, at 1:20 PM, Geo Carncross wrote: > > > This might actually be easier- All three supported databases (in a > > > way) > > > support a concept of access controls. With MySQL and Pg, each > > > "mailbox" > > > could be given a separate table (unless per-row grant rights are > > > possible), and then it'd be the SQL servers' job. Something they've > > > already got to spend a lot of effort into. > > > > At best that only limits the amount of damage an injection attack can > > do. If you want to protect against injection attacks, the only > > logical way to do it is to use bound parameters. > > The thing is it limits the amount of damage to the amount of damage that > could be caused anyway: What really is the difference between DELETE > FROM dbmail_physblah; and A01 DELETE INBOX > > > That doesn't mean that using appropriate database security isn't a > > good thing... it is. > > Unfortunately, at the moment, I don't know of any SQL engine that > supports row-based security except (maybe) SQLite... and as I already > mentioned SQLite can't be trusted because it's in-core.
There's support for it in PostgreSQL, just not out-of-the-box: http://pgfoundry.org/projects/veil/ But it'd be silly to go through all the trouble of setting up row-level security if you're not going to protect against injection attacks in the first place. Is there some reason why bound parameters aren't being used? Aside from the security aspect, they also provide a speed improvement. -- Jim C. Nasby, Database Architect [EMAIL PROTECTED] 512.569.9461 (cell) http://jim.nasby.net
