* Robert Haas (robertmhaas@gmail.com) wrote:
> On Tue, Feb 9, 2016 at 3:26 PM, Stephen Frost <sfrost@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