On May29, 2012, at 16:13 , Kohei KaiGai wrote:
> 2012/5/29 Florian Pflug <fgp@phlo.org>:
>> 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.
Nice to know that we're on the same page here.
>> 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.
Agreed. If the flag is per-role, not per-policy, the feature is orthogonal
to the whole RLS feature. So yeah, let's postpone it to a later date.
best regards,
Florian Pflug