On Tue, Apr 29, 2008 at 12:25 AM, Thomas Mueller <[EMAIL PROTECTED]> wrote:
> What do you think about it? Do you think it makes sense to implement > this security feature in PostgreSQL as well? If not why not? Does > PostgreSQL have another solution or plan to solve the SQL injection > problem? Damn, am I the only person who likes the idea? To those suggesting that it's just treating the symptom: well of course it is. But using e.g. Exec-Shield / PIE / stack protection weren't bad ideas just because buffer overflows are the fault of the application developer. And who wants to grep through every module they install on their system every time they do an update just in case some feature that they never use has added a bad query? Assuming they have the source. PHP apps are notorious for it, of course, but it isn't just them. Now, I reckon the only way to sanely do it without mucking up people's ad-hoc queries would be to have it as a permission that would default to on, but be REVOKE-able. Then it can be revoked from the user/role that $untrusted application connects as, but still allow people to get in from a trusted account and get their hands dirty when they need to. Would it catch ALL holes? No, as we saw in the order by case, and there are probably others (not sure if I like the proposed solution for that, btw). Would it catch a fair number? Absolutely. Cheers Tom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
