From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> |
Cc: | Robert Haas <robertmhaas(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-06-26 20:59:55 |
Message-ID: | 13017.1340744395@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> writes:
> 2012/6/26 Robert Haas <robertmhaas(at)gmail(dot)com>:
>> I think you're missing the point. Everyone who has commented on this
>> issue is in favor of having some check that causes the RLS predicate
>> *not to get added in the first place*.
> Here is a simple idea to avoid the second problematic scenario; that
> assign 0 as cost of has_superuser_privilege().
I am not sure which part of "this isn't safe" isn't getting through to
you. Aside from the scenarios Robert mentioned, consider the
possibility that f_malicious() is marked immutable, so that the planner
is likely to call it (to replace the call with its value) before it will
ever think about whether has_superuser_privilege should be called first.
Please just do what everybody is asking for, and create a bypass that
does not require fragile, easily-broken-by-future-changes assumptions
about what the planner will do with a WHERE clause.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2012-06-26 21:04:42 | Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap |
Previous Message | Robert Haas | 2012-06-26 20:58:44 | Re: pg_terminate_backend for same-role |