* Craig Ringer (cr...@2ndquadrant.com) wrote: > 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.
We'll need to work out how to ensure that things like current_user()
still returns the calling user in that case, otherwise it won't make any
sense. In general, I agree that having the RLS quals run as the table
owner is a good approach and would love to hear suggestions about how we
can make that happen.
> 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.
I don't particularly like this idea- it's akin, to me anyway, to making
the ability to control other permissions on a table (SELECT, INSERT,
etc) something which a user would have to be granted- and it doesn't
really address the issue.
Thanks,
Stephen
signature.asc
Description: Digital signature
