On Tue, Jul 7, 2015 at 2:24 PM, Stephen Frost <sfrost@snowman.net> wrote:
> * Claudio Freire (klaussfreire@gmail.com) wrote:
>> On Tue, Jul 7, 2015 at 12:34 PM, Stephen Frost <sfrost@snowman.net> wrote:
>> > * Heikki Linnakangas (hlinnaka@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.