* Craig Ringer (craig@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
