On 27 July 2015 at 21:58, Stephen Frost <sfrost@snowman.net> wrote:
> Dean,
>
> * Dean Rasheed (dean.a.rasheed@gmail.com) wrote:
>> On 27 July 2015 at 18:13, Joe Conway <mail@joeconway.com> wrote:
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA1
>> >
>> > On 07/27/2015 10:03 AM, Joe Conway wrote:
>> >> On 07/26/2015 07:59 AM, Joe Conway wrote:
>> >>> On 07/26/2015 07:19 AM, Dean Rasheed wrote:
>> >>>> Attached is an updated patch (still needs some docs for the
>> >>>> functions).
>> >>>
>> >>> Thanks for that. I'll add the docs.
>> >>
>> >> Documentation added. Also added comment to check_enable_rls about
>> >> passing InvalidOid versus GetUserId().
>> >>
>> >> I believe this is ready to go -- any other comments?
>> >
>> > Strike that - now I really think it is ready to go :-)
>> >
>> > In this patch I additionally changed instances of:
>> > check_enable_rls(indrelid, GetUserId(), true)
>> > to
>> > check_enable_rls(indrelid, InvalidOid, true)
>> > per Dean's earlier remark and my new comment.
>>
>> Looks good to me, except I'm not sure about those latest changes
>> because I don't understand the reasoning behind the logic in
>> check_enable_rls() when row_security is set to OFF.
>>
>> I would expect that if the current user has permission to bypass RLS,
>> and they have set row_security to OFF, then it should be off for all
>> tables that they have access to, regardless of how they access those
>> tables (directly or through a view). If it really is intentional that
>> RLS remains active when querying through a view not owned by the
>> table's owner, then the other calls to check_enable_rls() should
>> probably be left as they were, since the table might have been updated
>> through such a view and that code can't really tell at that point.
>
> Joe and I were discussing this earlier and it was certainly intentional
> that RLS still be enabled if you're querying through a view as the RLS
> rights of the view owner are used, not your own. Note that we don't
> allow a user to assume the BYPASSRLS right of the view owner though,
> also intentionally.
>
> As a comparison to what we do today, even if you have access to a table,
> if you query it through a view, it's the view owner's permissions which
> are used to determine access to the table through the view, not your
> own. I agree that can be a bit odd at times, as you can get a
> permission denied error when using the view even though you have access
> to the table which is complained about, but that's how views have worked
> for quite a long time.
>
OK, fair enough.
Regards,
Dean