On Tue, Jul 7, 2015 at 12:34 PM, Stephen Frost <sfr...@snowman.net> wrote: > * Heikki Linnakangas (hlinn...@iki.fi) wrote: >> On 07/07/2015 04:31 PM, Stephen Frost wrote: >> >The alternative is to have monitoring tools which are running as >> >superuser, which, in my view at least, is far worse. >> >> Or don't enable fpw_compression for tables where the information >> leak is a problem. > > My hope would be that we would enable FPW compression by default for > everyone as a nice optimization. Relegating it to a risky option which > has to be tweaked on a per-table basis, but only for those tables where > you don't mind the risk, makes a nice optimization nearly unusable for > many environments.
No, only tables that have RLS (or the equivalent, like in the case of pg_authid), where the leak may be meaningful. The attack requires control over an adjacent (same page) row, but not over the row being attacked. That's RLS. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
