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