Re: [RFC] Interface of Row Level Security

2012/5/29 Florian Pflug <fgp@phlo.org>:
> On May29, 2012, at 13:59 , Kohei KaiGai wrote:
>> 2012/5/28 Florian Pflug <fgp@phlo.org>:
>>> Concept B is handled adequately by the LEAKPROOF flag. Concept C is handled
>>> by the security_barrier flag. However, as you pointed out, it's a bit of a
>>> dubious concept and only really necessary for backwards compatibility because
>>> it reflects pre-9.2 behaviour.
>>>
>>> Concept A is what I was aiming for. Per the above, a per-RLS flag is clearly the
>>> wrong tool for the job, so consider my suggestion withdrawn. What we actually
>>> want, I think, is a per-role flag which marks a role as "leak trusted". Queries
>>> issued by such a role would behave as if all functions are LEAKPROOF, since even
>>> if there is a leak, the role is trusted not to exploit it.
>>>
>> It seems to me we are confusing about security-barrier and leakproof flag.
>> The purpose of leakproof flag is to ensure the function is safe to execute,
>> so it is allowed to pushed down the function into a sub-query with security-
>> barrier. It works to decide whether the user given qualifier is safe to
>> push-down. The RLS policy itself is placed within a sub-query from the
>> beginning, thus not needed them to be leakproof function.
>
> My suggestion (which I then withdrew) was for that per-policy flag to decide
> whether the sub-query which applies the RLS policy acts as a security barrier
> or not. Thus, with the flag set, only leakproof predicates would haven been
> allowed to be pushed down into that subquery, whereas without the flag every
> predicate would haven been a candidate for being pushed down. The flag was
> never intended to mark the RLS policy itself as leakproof or leaky - that,
> as you said, makes little sense.
>
> My motivation for suggesting that flag was to prevent people who want RLS,
> yet aren't concerned about leaks, from having to pay the performance penalty
> associated with not pushing down predicates.
>
I think it is a reasonable selection. For example, it make sense in case when
users obviously don't have privilege to create a function and don't care about
estimation of invisible values using iteration of proving.
The owner is the only person who can determine whether it is harmless, or not.

> Noah's comments, however, made me realize that whether one cares about
> potential leaks is usually not a per-table property, but rather a property
> of the user executing the query. Some users (like the middle-ware that sits
> on top of your database) you might trust to not exploit leaks, while wanting
> the tightest security possible for others. Which made me suggest a per-role
> flag which essentially overrides the security barrier stuff. Explaining that
> behaviour as "behave as if all functions are LEAKPROOF" might haven been a
> tad confusion, though. Maybe a better explanation is "behave as if no
> sub-query has the security barrier flag set", or even "don't let security
> concerns prevent predicate push-down".
>
Hmm... It might make sense to allow table-owner to set up suitable grade
between security and performance. However, isn't it a feature to be
discussed in the 2nd commit-fest? I think we can construct this type of
adjustment on the basis of minimum functionality.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>