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.
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?
regards, tom lane
