On Thu, Apr 16, 2015 at 4:26 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Wed, Apr 15, 2015 at 9:42 PM, Michael Paquier > <michael.paqu...@gmail.com> wrote: >> On Wed, Apr 15, 2015 at 9:20 PM, Michael Paquier >> <michael.paqu...@gmail.com> wrote: >>> On Wed, Apr 15, 2015 at 2:22 PM, Fujii Masao wrote: >>>> On Wed, Apr 15, 2015 at 11:55 AM, Michael Paquier wrote: >>>>> 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. >>>> >>>> I think that this patch is enough as the first step. >>> >>> I'll get something done for that at least, a big warning below the >>> description of wal_compression would do it. > > So here is a patch for this purpose, with the following text being used: > + <warning> > + <para> > + When enabling <varname>wal_compression</varname>, there is a risk > + to leak data similarly to the BREACH and CRIME attacks on SSL where > + the compression ratio of a full page image gives a hint of what is > + the existing data of this page. Tables that contain sensitive > + information like <structname>pg_authid</structname> with password > + data could be potential targets to such attacks. Note that as a > + prerequisite a user needs to be able to insert data on the same page > + as the data targeted and need to be able to detect checkpoint > + presence to find out if a compressed full page write is included in > + WAL to calculate the compression ratio of a page using WAL positions > + before and after inserting data on the page with data targeted. > + </para> > + </warning> > > Comments and reformulations are welcome.
To make things on this thread move on, I just wanted to add that we should make wal_compression SUSET without waiting if we make this parameter a reloption or not. As things stand, even if it is a reloption, any user can enforce its value in a given session. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
