Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Feb 9, 2016 at 3:01 PM, Joe Conway <m...@joeconway.com> wrote: > > On 02/09/2016 11:47 AM, Robert Haas wrote: > >> On Fri, Jan 15, 2016 at 11:53 AM, Stephen Frost <sfr...@snowman.net> wrote: > >>>> Whereupon you'd have no certainty that what you got represented a > >>>> complete dump of your own data. > >>> > >>> It would be a dump of what you're allowed to see, rather than an error > >>> saying you couldn't dump something you couldn't see, which is the > >>> alternative we're talking about here. Even if you've got a dependency > >>> to something-or-other, if you don't have access to it, then you're > >>> going to get an error. > >> > >> I think you're dismissing Tom's concerns far too lightly. The > >> row_security=off mode, which is the default, becomes unusable for > >> non-superusers under this proposal. That's bad. And if you switch to > >> the other mode, then you might accidentally fail to get all of the > >> data in some table you're trying to back up. That's bad too: that's > >> why it isn't the default. There's a big difference between saying > >> "I'm OK with not dumping the tables I can't see" and "I'm OK with not > >> dumping all of the data in some table I *can* see". > > > > I don't grok what you're saying here. If I, as a non-superuser could > > somehow see all the rows in a table just by running pg_dump, including > > rows that I could not normally see due to RLS policies, *that* would be > > bad. I should have no expectation of being able to dump rows I can't > > normally see. > > That's true. But I should also have an expectation that running > pg_dump won't trigger arbitrary code execution, which is why by > default, pg_dump sets row_security to OFF. That way, if a row > security policy applies, I get an error rather than an incomplete, > possibly-invalid dump (and arbitrary code execution on the server > side). If I'm OK with doing the dump subject to row security, I can > rerun with --enable-row-security. But this proposal would force > non-superusers to always use that option, and that's not a good idea.
Arbitrary code execution is quite a different concern from the prior concern regarding incomplete dumps. To the extent that untrusted code execution is an issue (and my experience with environments which would deploy RLS tells me that it isn't a practical concern), an option could be created which would cause an error to be thrown on non-catalog RLS being run. When it comes to multi-tenancy environments, as this thread is about, chances are the only tables you can see are ones which you own or are owned by a trusted user, which is why I don't view this as a pratical concern, but I'm not against having a solution to address the issue raised regarding arbitrary code execution, provided it doesn't create more problems than it purports to solve. Thanks! Stephen
signature.asc
Description: Digital signature
