Re: row_security GUC, BYPASSRLS - Mailing list pgsql-hackers

On Tue, Sep 22, 2015 at 10:38:53AM -0400, Stephen Frost wrote:
> * Noah Misch (noah@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