On Thu, May 24, 2012 at 07:31:37PM +0200, Florian Pflug wrote: > On May24, 2012, at 18:42 , Kohei KaiGai wrote: > > As we discussed, it causes a problem with approach to append > > additional qualifiers to where clause implicitly, because it does > > not solve the matter corresponding to the order to execute > > qualifiers. So, I'm inclined to the approach to replace reference > > to tables with security policy by sub-queries with security barrier > > flag. > > Since the security barrier flag carries a potentially hefty performance > penalty, I think it should be optional. Application which don't allow > SQL-level access to the database might still benefit from row-level security, > because it saves them from having to manually add the WHERE clause to every > statement, or having to wrap all their tables with views. Yet without direct > SQL-level access, the security barrier thing isn't really necessary, so > it'd be nice if they wouldn't have to pay for it. How about > > ALTER TABLE ? SET ROW POLICY ? WITH (security_barrier)
The conventional case for a RLS facility is to wholly implement a security policy, so security_barrier should be the default. Using the same facility to implement a security policy in cooperation with a trusted query generator is the variant case. Backward compatibility concerns limited our options when retrofitting the security_barrier treatment for views, but I'd rather not add a knob completely disabling it in the context of a brand new feature. A better avenue is to enhance our facilities for identifying safe query fragments. For example, ALTER FUNCTION ... LEAKPROOF is superuser-only. Adding a way for a table owner to similarly trust functions for the purpose of his own tables would help close the gap that motivates such an all-or-nothing knob. Thanks, nm -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
