| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, "ktm(at)rice(dot)edu" <ktm(at)rice(dot)edu>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Oleg Bartunov <obartunov(at)gmail(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, PgHacker <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [v9.4] row level security |
| Date: | 2013-09-04 14:50:49 |
| Message-ID: | 1543.1378306249@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Sep 4, 2013 at 10:45 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Well, the security-barrier view stuff did not present itself as a 100%
>> solution. But perhaps more to the point, it was conceptually simple to
>> implement, ie don't flatten views if they have this bit set, and don't
>> push down quals into such sub-selects unless they're marked leakproof.
> 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?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2013-09-04 14:53:19 | Re: [tiny doc fix] statistics are not retained across immediate shutdown |
| Previous Message | Robert Haas | 2013-09-04 14:48:47 | Re: [v9.4] row level security |