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.
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".
best regards,
Florian Pflug