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. > 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... 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
