On Tue, Sep 22, 2015 at 10:38:53AM -0400, Stephen Frost wrote: > * Noah Misch (n...@leadboat.com) wrote: > > On Mon, Sep 21, 2015 at 09:30:15AM -0400, Stephen Frost wrote: > > > One item which wasn't discussed, that I recall, is just how it will work > > > without SECURITY_ROW_LEVEL_DISABLED, or something similar, to > > > differentiate when internal referencial integrity queries are being run, > > > which should still bypass RLS (even in the FORCE ROW SECURITY case), and > > > when regular or SECURITY DEFINER originated queries are being run. > > > > If the table owner enables FORCE ROW SECURITY, policies will affect > > referential integrity queries. Choose policies accordingly. For example, > > given only ON UPDATE NO ACTION constraints, it would be no problem to set > > owner-affecting policies for INSERT, UPDATE and/or DELETE. > > Perhaps I'm not following correctly, but the above doesn't look correct > to me. An ON UPDATE NO ACTION constraint would run a query against the > referring table (which has FORCE ROW SECURITY set, perhaps by mistake > after a debugging session of the owner, with a policy that does not > allow any records to be seen by the owner), fail to find any rows, and > conclude that no error needs to be thrown, resulting in the referring > table having records which refer to keys in the referred-to table that > no longer exist (the UPDATE having changed them).
Yes, the table owner could define policies that thwart referential integrity. > This would lead to trivial to cause (and likely hard to diagnose) > referential integrity data corruption issues. I find that a very hard > pill to swallow in favor of a theoretical concern that new code may open > avenues of exploit for a new security context mode to bypass RLS when > doing internal referential integrity checks. Further, it changes this > additional capability, which was agreed would be added to offset removal > of the 'row_security = force' option, from useful to downright > dangerous. In schema reviews, I will raise a red flag for use of this feature; the best designs will instead use additional roles. I forecast that PostgreSQL would fare better with no owner-constrained-by-RLS capability. Even so, others want it, and FORCE ROW SECURITY would deliver it with an acceptable risk profile. "SET row_security=force" was too risky, and not in a way particular to foreign key constraints, because the session user chose row_security=force independent of object owners. With FORCE ROW SECURITY, each table owner would make both decisions. A foreign key constraint, plus a SELECT policy hiding rows from the table owner, plus FORCE ROW SECURITY is one example of self-contradictory policy design. That example is unexceptional amidst the countless ways a table owner can get security policy wrong. SECURITY_ROW_LEVEL_DISABLED could have been okay. I removed an incomplete implementation (e.g. didn't affect CASCADE constraints). Writing a full one would be a mammoth job, and for what? Setting the wrong SELECT policies can disrupt _any_ application logic; no foreign keys or FORCE ROW SECURITY need be involved. Protecting just foreign keys brings some value, but it will not materially reduce the vigilance demanded of RLS policy authors and reviewers. nm -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
