2012/5/23 Alastair Turner <[email protected]>: > On Wed, May 23, 2012 at 5:09 PM, Tom Lane <[email protected]> wrote: >> Kohei KaiGai <[email protected]> writes: >>> Let me have a discussion to get preferable interface for row-level security. >>> My planned feature will perform to append additional conditions to WHERE >>> clause implicitly, to restrict tuples being visible for the current user. >>> For example, when row-level policy "uname = getpgusername()" is configured >>> on the table T1, the following query: >>> select * from T1 where X > 20; >>> should be rewritten to: >>> select * from T1 where (X > 20) AND (uname = getpgusername()); >> >> Hm. Simple and fairly noninvasive, but ... would this not be subject to >> the same sorts of information-leak hazards that were addressed in the >> "security views" feature? That is, I see no guarantee that the RLS >> condition will be evaluated before any conditions supplied by the user. >> So it seems easy to get information out of rows the RLS policy is >> supposed to prevent access to. It would be far more secure to just >> use a security view to apply the RLS condition. > > Since adding a condition to the where clause is a relatively simple > operation (compared to the full potential scope of a view) could the > RLS rewrite of the query create a CTE with the additional condition[s] > rather than adding condition[s] to the user-supplied query? This would > provide the forced ordering of the evaluating the conditions, thereby > avoiding many of the potential points of leakage. > An interesting idea. However, I cannot imagine how does it works on update or delete statement.
For select statement, it will get better performance to rewrite reference to a particular table by a subquery with security_barrier flag than CTE, because it allows to push down leakproof functions. Could you tell me your idea for more details? An example will help me understand well. Thanks, -- KaiGai Kohei <[email protected]> -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
