Dean, * Dean Rasheed ([email protected]) wrote: > On 27 July 2015 at 18:13, Joe Conway <[email protected]> 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.
Thanks!
Stephen
signature.asc
Description: Digital signature
