On Mon, Sep 14, 2015 at 03:29:16AM -0400, Noah Misch wrote: > On a related topic, check_enable_rls() has two kinds of RLS bypass semantics. > Under row_security=off|on, superusers bypass every policy, and table owners > bypass policies of their own tables. Under row_security=off only, roles with > BYPASSRLS privilege additionally bypass every policy; BYPASSRLS doesn't affect > semantics under row_security=on. Is that distinction a good thing? Making > BYPASSRLS GUC-independent, like superuser bypass, would simplify things for > the user and would make row_security no longer a behavior-changing GUC. > row_security would come to mean simply "if a policy would otherwise attach to > one of my queries, raise an error instead." Again, if you have cause to > toggle BYPASSRLS, use multiple roles. Implementing that with GUCs creates > harder problems.
Having pondered this further in the course of finalizing commit 537bd17, arming BYPASSRLS independent of the row_security GUC is indeed a good thing. Right now, if a BYPASSRLS user creates a SECURITY DEFINER function, any caller can change that function's behavior by toggling the GUC. Users won't test accordingly; better to have just one success-case behavior. On Wed, Jul 29, 2015 at 09:09:27AM -0400, Stephen Frost wrote: > For superuser (the only similar precedent that we have, I believe), we > go based on the view owner, but that isn't quite the same as BYPASSRLS. > > The reason this doesn't hold is that you have to use a combination of > BYPASSRLS and row_security=off to actually bypass RLS, unlike the > superuser role attribute which is just always "on" if you've got it. If > having BYPASSRLS simply always meant "don't do any RLS" then we could > use the superuser precedent to use what the view owner has, but at least > for my part, I'm a lot happier with BYPASSRLS and row_security than with > superuser and would rather we continue in that direction, where the user > has the choice of if they want their role attribute to be in effect or > not. If I make BYPASSRLS GUC-independent, I should then also make it take effect when the BYPASSRLS role owns a view. Barring objections, I will change both. I do share your wish for an ability to suppress privileges temporarily. I have no specific design in mind, but privilege activation and suppression should be subject to the approval of roles affected. GUCs probably can't serve here; apart from the grandfathered search_path, functions can ignore them. GUCs are mostly a property of the whole session. By the way, is there a reason for RI_Initial_Check() to hard-code the rules for RLS enablement instead of calling check_enable_rls(..., InvalidOid, true) twice? I refer to this code: > /* > * Also punt if RLS is enabled on either table unless this role has the > * bypassrls right or is the table owner of the table(s) involved which > * have RLS enabled. > */ > if (!has_bypassrls_privilege(GetUserId()) && > ((pk_rel->rd_rel->relrowsecurity && > !pg_class_ownercheck(pkrte->relid, GetUserId())) || > (fk_rel->rd_rel->relrowsecurity && > !pg_class_ownercheck(fkrte->relid, GetUserId())))) > return false; -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
