On May29, 2012, at 16:57 , Kohei KaiGai wrote: > 2012/5/29 Robert Haas <robertmh...@gmail.com>: >> One idea might be to have a grantable permission that permits the RLS >> policy to be bypassed. So, if a user has only SELECT permission, they >> can select from the table, but the RLS policy will apply. If they >> have both SELECT and RLSBYPASS (probably not what we really want to >> call it) permission, then they can select from the table and the RLS >> policy will be skipped. This means that superusers automatically skip >> all RLS policies (which seems right) and table owners skip them by >> default (but could revoke their own privileges) and other people can >> skip them if the table owner (or the superuser) grants them the >> appropriate privilege on the table involved.
> Isn't it unavailable to describe using RLS policy? > In case when 'alice' and 'bob' should bypass RLS policy on a certain table, > we will be able to describe it as follows: > (current_user in ('alice', 'bob') OR rls_policy_this_table(X, Y, Z)) > > I have one concern the "current_user in (...)" is not wiped out at the planner > stage, although its evaluation result is obvious prior to execution. I think you'd simply pretend the RLS policy isn't there (i.e., don't rewrite the table reference into a sub-query) if the user has the RLSBYPASS privilege, not add another clause which selectively neuters the RLS policy. Wait a moment.. now I get it. You're saying that Robert's RLSBYPASS privilege is redundant, since one can always add a "current_user IN ..." clause to the RLS policy function. That might be the case theoretically, but I still believe that Robert's suggestion has a lot of benefits. First, due to role inheritance, a simply clause like the above isn't sufficient. Second, it doesn't make superusers and table owner bypass RLS by default. Which I think is a good idea (bypassing by default, that is), because it prevents broken backups (for those using pg_dump) and data exports. It doesn't cost anything in terms of security, because those users could disable the RLS policy away if they are so inclined. best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers