2012/5/23 Tom Lane <t...@sss.pgh.pa.us>: > Kohei KaiGai <kai...@kaigai.gr.jp> 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. > I wanted to have discussion to handle this problem.
Unlike leaky-view problem, we don't need to worry about unexpected qualifier distribution on either side of join, because a scan on table never contains any join. Thus, all we need to care about is order of qualifiers chained on a particular scan node; being reordered by the cost to invoke functions. How about an idea to track FuncExpr come from the security policy and enforce "0" on its cost? Regular functions never reach zero cost, so the security policy must be re-ordered to the head. > Also, if the point here is to provide security for tables not views, > it seems like you really need to have (at least a design for) RLS > security on insert/update/delete operations. Just adding the same > filter condition might be adequate for deletes, but I don't think it > works at all for inserts. And for updates, what prevents the user from > updating columns he shouldn't, or updating them to key values he > shouldn't be able to use? > If we also apply the security policy to newer version of tuples on update and insert, one idea is to inject a before-row-(update|insert) trigger to check whether it satisfies the security policy. For same reason, the trigger should be executed at the end of trigger chain. 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
