* Peter Geoghegan (pg@heroku.com) wrote:
> On Mon, Jun 1, 2015 at 12:29 AM, Peter Geoghegan <pg@heroku.com> 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.
It's important to realize that this is an issue beyond RLS and that it
impacts Security Barrier Views also.
One idea which I have for making the documentation patch a bit less
clunky is to provide a simple way for users to address the issue. Along
those lines, here's what I'd suggest (certainly open for discussion):
-----------------------
When reducing the set of rows which a user has access to, through
modifications to relations referenced by Row-Level Security Policies or
Security Barrier Views, be aware that users with a currently open
transaction might have a lock on an existing row and be able to see that
row after the change. The best approach to avoid any possible leak of
information during a reduction of a user's rights is to ensure that the
user does not have any open transactions, perhaps by ensuring they have
no concurrent sessions running.
-----------------------
Thoughts? Trying to keep it straight-forward and provide a simple
solution for users to be able to address the issue, if they're worried
about it. Perhaps this, plus an additional paragraph which goes into
more detail about exactly what's going on?
Thanks!
Stephen
