Re: [v9.4] row level security

On 11/07/2013 06:11 PM, Dean Rasheed wrote:
> I don't really get this part of the discussion. Why would you want to
> make updatable SB views do any of that?

I don't, especially. If we're going to use updatable SB views as the
basis for RLS then we need the option to skip adding the qual for superuser.

That might be done outside the SB code its self, by not invoking the SB
view rewrite on the base rel when we see we're running as an RLS-exempt
user. It's all about dealing with the re-plan problem really.

> With SB views, however, you can have multiple SB views on top of the
> same base table, each giving different users access to different
> subsets of the data, and controlled by suitable GRANTs, and suitably
> privileged users can be given direct access to the base table. This
> also gives greater flexibility than the superuser/non-superuser
> distinction being discussed here.

That's a thought.

Can we munge what the planner sees in pg_class instead? So when we see a
ref to an RLS relation we transparently substitute the oid for a hidden
SB view over the relation instead. For RLS exempt users we omit that
substitution.

Since the lookups and view subs are done in the rewrite phase it
probably doesn't help us much, but it'd get rid of the need to play
about with substituting a RTE_RELATION with an RTE_SUBQUERY dynamically
during rewrite.

> I don't think a view should ever show different data to different
> users (unless it has been deliberately set up to do so) because that
> would likely lead to confusion. Is there some other use-case that I'm
> missing here?

The main concern is pg_dump - it's important that dumps be able to take
a complete copy without relying on hacks or bug-free user-written RLS quals.

Highly privileged users should also be exempt from RLS so they don't
invoke untrusted functions that're part of RLS quals written by
lower-rights users.

This isn't really "superuser" vs "not superuser. In fact we'll want a
new right that controls whether RLS can be bypassed, and another that
controls the ability to set RLS rights on tables. Both of those would be
superuser only by default, but could be delegated.

(Note: It's important that table owners _not_ get the right to set RLS
on tables by default for security reasons. I'll explain in more detail
later.)

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services