On Mon, Nov 11, 2013 at 11:10 PM, Craig Ringer <cr...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
