On Wed, May 23, 2012 at 5:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Kohei KaiGai <kaigai@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.
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.
Bell.