Craig Ringer <cr...@2ndquadrant.com> writes: > On 06/11/2014 07:24 AM, Tom Lane wrote: >> Is the point of that that the table owner might have put trojan-horse >> functions into the RLS qual? If so, why are we only concerned about >> defending the superuser and not other users? Seems like the right fix >> would be to insist that functions in the RLS qual run as the table owner. >> Granted, that might be painful to do. But it still seems like "we only >> need to do this for superusers" is designing with blinkers on.
> I agree, and now that the urgency of trying to deliver this for 9.4 is > over it's worth seeing if we can just run as table owner. > Failing that, we could take the approach a certain other RDBMS does and > make the ability to define row security quals a GRANTable right > initially held only by the superuser. Hmm ... that might be a workable compromise. I think the main issue here is whether we expect that RLS quals will be something that the planner could optimize to any meaningful extent. If they're always (in effect) wrapped in SECURITY DEFINER functions, I think that largely blocks any optimizations; but maybe that wouldn't matter in practice. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers