Re: API change advice: Passing plan invalidation info from the rewriter into the planner?

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
>> I'm really concerned about the security implications of this patch. I
>> think we're setting ourselves up for a whole lot of hurt for somewhat
>> unclear gain.

> I'm certainly of a different opinion and, for the most part, I feel that
> if there are security concerns then they need to be addressed- and
> better by us than by asking users to use some other mechanism to
> implement RLS.

TBH, I found Robert's argument pretty persuasive. The idea that
"SELECT * FROM table" might invoke arbitrary processing ought to scare
anyone who's concerned about security, because that's going to completely
break any assumptions about pg_dump being safe for instance, as well as
force top-to-bottom rethinking of many other security assumptions.

> ... That commit was
> the ground-work to allow us to finally get proper RLS and I'm very
> disappointed to hear that the mechanical pieces around making RLS easy
> for users to use (and getting that check-box taken care of in a wide
> variety of fields that we are being exposed to now, see the PGConf.NYC
> keynote speakers...) is receiving such push-back.

If this is being sold as merely "ease of use", then it is probably going
to get rejected. In order to get some extra ease of use for the minority
of users who need RLS, you are going to significantly complicate the lives
of all Postgres users. That's not a net win in any sane calculation of
ease of use.

Maybe the right thing to think about is how we can make it easier to set
up table + view combinations according to the pattern Robert described.
I wouldn't have a problem with some more-or-less-automated support for
doing that. (Consider SERIAL as a possible precedent here: it's basically
a table creation macro.)

> You're suggesting that we use views instead, which clearly could run
> someone else's code. Perhaps the user will notice that they're
> selecting from a view instead of a table, but I've never seen a security
> design around making sure that what is being select'd from is a table
> vs. a view.

pg_dump is a sufficient counterexample to that statement.

regards, tom lane