On Mon, Nov 11, 2013 at 11:10 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
> On 11/11/2013 06:37 PM, Kohei KaiGai wrote:
>> I'd like to vote the last options. It is a separate problem (or, might
>> be specification), I think.
>
> I tend to agree, but I'm nervous about entirely hand-waving around this,
> as doing so would *expand* the existing problem.
Suppose we define a new GUC, allow_row_level_security, which defaults
to true. When set to false, any attempt to access a table protected
with RLS will either (1) bypass RLS, if you have sufficient privileges
to do that (presumably table owner and superuser, at least, would be
sufficient) or (2) fail with an error if RLS cannot be bypassed. But,
when allow_row_level_security is false, *under no circumstances* will
we evaluate RLS quals - it's bypass-or-error.
Then, we can teach pg_dump to set allow_row_level_security = false on
server versions >= 9.4, with an option --allow-row-level-security that
bypasses this behavior.
With these changes, pg_dump is safe by default, not only against
hijacking attacks but against accidentally failing to dump all the
data because you fail to realize that you're subject to an RLS qual.
You'll either get a clean, restorable dump, or you'll fail with an
easy-to-understand error. In the latter case, if you want to try to
back up that portion of the table you can access, there's an option
for that behavior, which can be documented to imply trust in the table
owner.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
