On Tue, Jul 7, 2015 at 2:24 PM, Stephen Frost <sfr...@snowman.net> wrote: > * Claudio Freire (klaussfre...@gmail.com) wrote: >> 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. > > Eh? I don't recall Heikki's attack requiring RLS and what about > column-level privilege cases where you have access to the row but not to > one of the columns?
That's right, column-level too. Heiki's "change password" step requires something very similar to RLS where roles can only update their own row. pg_authid also has column-level stuff, where you only see your own hashed password, and that too may make the attack useful. In the absence of row or column-level privileges, however, the attack is unnecessary, and FPW compression can be applied liberally. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
