2012/6/5 Florian Pflug <f...@phlo.org>: > On Jun5, 2012, at 10:22 , Kohei KaiGai wrote: >> 2012/6/5 Tom Lane <t...@sss.pgh.pa.us>: >>> I suspect that KaiGai-san's objection basically comes down to not >>> wanting to have what amounts to a backdoor in RLS policies. However, >>> what Florian is saying is that you have to have a backdoor anyway, >>> unless you'd like to be at risk of losing data because it wasn't >>> backed up. You can either have one well-understood, well-documented, >>> well-tested backdoor, or you can have an ad-hoc backdoor in each RLS >>> policy. Nobody can think that the latter approach is preferable. > >> At least, database superusers shall bypass the RLS policy; it is a well >> understandable behavior and an approach to minimize the back-door; >> and allows to get complete database backup. > > I don't think we want to force people to run stuff with superuser > privileges just for the sake of bypassing a RLS policy. On the whole, > that reduces the overall security, not adds to it. > I can understand your opinion. But I'm still uncertain whether the new permission is the best idea we can offer...
>> It is easy to add a special privilege mechanism to bypass RLS policy >> later, however, not easy in opposite side. It seems to me a reasonable >> start-up to allow only superusers to bypass RLS policy. > > What's to be gained by that? Once there's *any* way to bypass a RLS > policy, you'll have to deal with the plan invalidation issues you > mentioned anyway. ISTM that complexity-wide, you don't save much by not > having RLSBYPASS (or something similar), but feature-wise you lose at > lot... > All we need to change is selection of the function to be appended automatically. In case when superusers are allowed to bypass RLS policy, "OR has_superuser_privilege()" shall be appended to the user given clause, however, "OR has_table_privilege()" shall be appended instead in case of RLSBYPASS permission. (Note that has_table_privilege() always true for superusers.) I think it does not require to add a mechanism to invalidate prepared-statement, because all the checks are applied on executor stage. And these functions can be stable functions, so I believe some enhancements at planner will correctly wipe out prior to query execution at the next step. Conditional RLS policy in planner stage seems to me problematic so I don't want to include this feature on the first version. 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
