Re: Arguable RLS security bug, EvalPlanQual() paranoia

Robert,

As I mentioned up thread, I'm out until the 27th. I have posted a patch
which I will push to fix the copy.c issue, and I have already stated that
I'll address the statistics issue. Further, Joe has also been working on
issues but he was out of pocket last week attending a conference.

I'm happy to work up a documentation patch for this when I get back.

Thanks!

Stephen

On Tuesday, July 21, 2015, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Sun, Jul 19, 2015 at 8:56 PM, Peter Geoghegan <pg(at)heroku(dot)com
> <javascript:;>> wrote:
> > On Mon, Jun 1, 2015 at 12:29 AM, Peter Geoghegan <pg(at)heroku(dot)com
> <javascript:;>> wrote:
> >> If you're using another well known MVCC database system that has RLS,
> >> I imagine when this happens the attacker similarly waits on the
> >> conflicting (privileged) xact to finish (in my example in the patch,
> >> Bob's xact). However, unlike with the Postgres READ COMMITTED mode,
> >> Mallory would then have her malicious UPDATE statement entirely rolled
> >> back, and her statement would acquire an entirely new MVCC snapshot,
> >> to be used by the USING security barrier qual (and everything else)
> >> from scratch. This other system would then re-run her UPDATE with the
> >> new MVCC snapshot. This would repeat until Mallory's UPDATE statement
> >> completes without encountering any concurrent UPDATEs/DELETEs to her
> >> would-be affected rows.
> >>
> >> In general, with this other database system, an UPDATE must run to
> >> completion without violating MVCC, even in READ COMMITTED mode. For
> >> that reason, I think we can take no comfort from the presumption that
> >> this flexibility in USING security barrier quals (allowing subqueries,
> >> etc) works securely in this other system. (I actually didn't check
> >> this out, but I imagine it's true).
> >
> > Where are we on this?
> >
> > Discussion during pgCon with Heikki and Andres led me to believe that
> > the issue is acceptable. The issue can be documented to help ensure
> > that user expectation is in line with actual user-visible behavior.
> > Unfortunately, I think that that will be a clunky documentation patch.
>
> Perhaps I'm missing something, but it looks to me like Stephen has
> done absolutely nothing about the many issues reported with the RLS
> patch. I organized the open items list by topic on June 26th; almost
> a month later, four more issues have been added to the section on RLS,
> and none have been removed.
>
> I think it is right that we should be concerned about this.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>