Re: FPW compression leaks information

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, hlinnaka <hlinnaka(at)iki(dot)fi>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FPW compression leaks information
Date: 2015-04-15 03:16:25
Message-ID: CAB7nPqTFuiyPm6NGRWHcUVXLiadM9t-eX52W2Gr-4XLBwcMKeQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 15, 2015 at 11:55 AM, Michael Paquier wrote:
> OK. I am fine to implement anything required here if needed, meaning
> the following:
> 1) Doc patch to mention that it is possible that compression can give
> hints to attackers when working on sensible fields that have a
> non-fixed size.
> 2) Switch at relation level to control wal_compression. This needs to
> change XLogRecordAssemble by adding some new logic to check if a
> relation is enforcing WAL compression or not. As a reloption, there
> are three possible values: true, false and fallback to system default.
> Also, I think that we should simply extend XLogRegisterBuffer() and
> pass to it the reloption flag that is then registered in
> registered_buffer, and XLogRecordAssemble() decides with this flag if
> block is compressed or not. Do we want to add this reloption switch to
> indexes as well? Or only tables? For indexes things will get heavier
> as we would need to add a parameter for all the index types.

After looking at reloptions.c, what we are going to need as well is a
new relopt_type, like RELOPT_TYPE_ENUM for this purpose to be able to
define the 'default' value. We could as well have things using
RELOPT_TYPE_STRING. Any input on this matter is welcome.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2015-04-15 03:31:59 Re: FPW compression leaks information
Previous Message Michael Paquier 2015-04-15 02:55:07 Re: FPW compression leaks information