| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Florian Pflug <fgp(at)phlo(dot)org>, PgHacker <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [v9.3] Row-Level Security |
| Date: | 2012-10-22 16:17:33 |
| Message-ID: | 2993.1350922653@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:
> The documentation lists several documented limitations that I would
> like to analyze a little bit. First, it says that row-level security
> policies are not applied on UPDATE or DELETE. That sounds downright
> dangerous to me. Is there some really compelling reason we're not
> doing it?
[ blink... ] Isn't that a security hole big enough for a Mack truck?
UPDATE tab SET foo = foo RETURNING *;
sucks out all the data just fine, if RLS doesn't apply to it.
Having said that, I fear that sensible row-level security for updates is
at least one order of magnitude harder than sensible row-level security
for selects. We've speculated about how to define that in the past,
IIRC, but without any very satisfactory outcome.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2012-10-22 16:25:42 | Re: [PATCH] Support for Array ELEMENT Foreign Keys |
| Previous Message | Andres Freund | 2012-10-22 16:13:20 | Re: [PATCH] Support for Array ELEMENT Foreign Keys |