Re: FPW compression leaks information

On Wed, Jul 8, 2015 at 12:34 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Heikki Linnakangas (hlinnaka(at)iki(dot)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.
>
>> >I'm not following. If we don't want the information to be available to
>> >everyone then we need to limit it, and right now the only way to do that
>> >is to restrict it to superuser because we haven't got anything more
>> >granular.
>> >
>> >In other words, it seems like your above response about not wanting this
>> >to be available to anyone except superusers is counter to this last
>> >sentence where you seem to be saying we should continue to have the
>> >information available to everyone and simply document that there's a
>> >risk there as in the proposed patch.
>>
>> I don't think we can or should try to hide the current WAL location.
>> At least not until we have a monitoring role separate from
>> superuserness.

+1

> I'd rather we hide it now, to allow FPW compression to be enabled for
> everyone, except those few environments where it ends up making things
> worse, and then provide the monitoring role in 9.6 which addresses this
> and various other pieces that are currently superuser-only. We could
> wait, but I think we'd end up discouraging people from using the option
> because of the caveat and we'd then spend years undoing that in the
> future.

So one (ugly) idea is to introduce new setting value like
more_secure_but_might_break_your_monitoring_system (better name? ;))
in wal_compression. If it's specified, literally FPW is compressed and
non-superuser is disallowed to see WAL locaiton. This isn't helpful for
those who need WAL compression but want to allow even non-superuser
to see WAL location, though. Maybe we need to implement also per-table
FPW compression option, to alleviate this situation.

Or another crazy idea is to append "random length" dummy data into
compressed FPW. Which would make it really hard for an attacker to
guess the information from WAL location. Even if this option is enabled,
you can still have the performance improvement by FPW compression
(of course if dummy data is not so big).

Regards,

--
Fujii Masao