On 8 April 2015 at 16:27, Stephen Frost <sfrost@snowman.net> wrote:
>> 2). In prepend_row_security_policies(), I think it is better to have
>> any table RLS policies applied before any hook policies, so that a
>> hook cannot be used to bypass built-in RLS.
>
> While I agree that we want to include the RLS policies defined against
> the table prior to any policies which are added by the hook, I don't
> quite follow what you mean by "cannot be used to bypass built-in RLS".
> If we allow, as intended, extensions to define their own policies then
> it's entirely possible for the extension to return a "allow all" policy,
> and I believe that's perfectly fine.
>
That doesn't match what the code currently does:
* Also, allow extensions to add their own policies. * * Note that, as with the internal policies, if multiple
policiesare * returned then they will be combined into a single expression with * all of them OR'd together.
However,to avoid the situation of an * extension granting more access to a table than the internal policies *
wouldallow, the extension's policies are AND'd with the internal * policies. In other words - extensions can only
providefurther * filtering of the result set (or further reduce the set of records * allowed to be added).
which seems reasonable, and means that if there are both internal and
external policies, an "allow all" external policy would be a no-op.
All the patch does is to ensure that the quals from the external
policies are on the outer security barrier, so that if they contain
leaky functions they cannot leak data that doesn't pass the internal
policies (like a SB view on top of another SB view).
Regards,
Dean