Re: [RFC] Interface of Row Level Security

On May28, 2012, at 02:46 , Noah Misch wrote:
> On Thu, May 24, 2012 at 07:31:37PM +0200, Florian Pflug wrote:
>> 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)
>
> 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.

Hm, I'm not sure a per-function flag is really the solution here. Neither,
however, is a per-RLS flag as your arguments made me realize. There really are
three orthogonal concepts here, all of which allow security barriers to be
ignored, namely

A) Trusting the use not to exploit leaks, i.e. what you call a trusted query
generator

B) There being no leaks, i.e. all functions being LEAKPROOF

C) Not caring about leaks, i.e. the security_barrier flag

Concept B is handled adequately by the LEAKPROOF flag. Concept C is handled
by the security_barrier flag. However, as you pointed out, it's a bit of a
dubious concept and only really necessary for backwards compatibility because
it reflects pre-9.2 behaviour.

Concept A is what I was aiming for. Per the above, a per-RLS flag is clearly the
wrong tool for the job, so consider my suggestion withdrawn. What we actually
want, I think, is a per-role flag which marks a role as "leak trusted". Queries
issued by such a role would behave as if all functions are LEAKPROOF, since even
if there is a leak, the role is trusted not to exploit it.

best regards,
Florian Pflug