Re: [v9.4] row level security

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Sep 4, 2013 at 10:50 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> Right. IMHO, this new feature should be similarly simple: when an
>>> unprivileged user references a table, treat that as a reference to a
>>> leakproof view over the table, with the RLS qual injected into the
>>> view.

>> And for insert/update/delete, we do what exactly?

> The same mechanism will prevent UPDATE and DELETE from seeing any rows
> the user shouldn't be able to touch.

No, it won't, because we don't support direct update/delete on views
(and if you look, you'll notice the auto-updatable-view stuff doesn't
think a security-barrier view is auto-updatable).

AFAICT, to deal with update/delete the RLS patch needs to constrain order
of qual application without the crutch of having a separate level of
subquery; and it's that behavior that I have zero confidence in, either
as to whether it works as submitted or as to our odds of not breaking it
in the future.

regards, tom lane