2012/5/29 Florian Pflug <f...@phlo.org>: > 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. > 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 <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers