* Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Feb 9, 2016 at 3:26 PM, Stephen Frost <sfr...@snowman.net> wrote: > > 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. > > There's a major release already in the wild that doesn't behave that > way.
I'm at a loss as to what you're getting at there. We don't have any catalog RLS, and when it comes to non-catalog RLS, we do have an option to throw an error when it's going to be run (and it's the default, as you pointed out), in the one major version which supports RLS. > And anyway I think that's missing the point: it's true that > features that are turned off don't cause problems, but features that > are turned on shouldn't break things either. I don't, generally, disagree with that statement, but we have to agree on what's on vs. off and what is broken vs. working correctly. See nearby comments from JD about how non-superuser pg_dump could be seen as broken when running against an environment where RLS is in use. > > 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. > > Well, I'm against accepting this patch without such a solution. That's at least something which can be built upon then to help this progress. Thanks! Stephen
signature.asc
Description: Digital signature
