Re: row_security GUC, BYPASSRLS

On Mon, Sep 21, 2015 at 09:30:15AM -0400, Stephen Frost wrote:
> * Noah Misch (noah(at)leadboat(dot)com) wrote:
> > 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.
>
> I agree that's not good, though the function definer could set the
> row_security GUC on the function, no? Similar to how we encourage
> setting of search_path, we should be encouraging a similar approach to
> anything which might be security relevant.

Functions can do that. New features should not mimic search_path in their
demands on SECURITY DEFINER authors.

> Are you planning to handle the ALTER TABLE .. FORCE ROW SECURITY (#3) as
> well? I have no complaints if so; just want to make sure we aren't
> doing double-work during this crunch time and didn't see your name
> listed next to it, but the nearby thread seemed to imply you were
> looking at it.

I'm not.

> 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.