Re: FPW compression leaks information

* Fujii Masao (masao(dot)fujii(at)gmail(dot)com) wrote:
> On Wed, Jul 8, 2015 at 12:34 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > 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.

I'm not thrilled with that idea, but at the same time, we could have a
generic "hide potentially sensitive information" option that applies to
all of these things and then admins could set that on their monitoring
role, to allow it to see the data. That wouldn't get in the way of the
default roles idea either.

> 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).

I'm not sure I'd call that "crazy" as it's done in other systems.. This
would also help with cases where an attacker can view the WAL length
through other means, so it has some indepdent advantages.

Curious to hear what others think about that approach though.

Thanks!

Stephen