On May29, 2012, at 13:59 , Kohei KaiGai wrote: > 2012/5/28 Florian Pflug <f...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers