Re: FPW compression leaks information

* Magnus Hagander (magnus(at)hagander(dot)net) wrote:
> On Tue, Apr 14, 2015 at 4:50 PM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> > I'm not a big fan of locking down WAL position information either. If we
> > have to treat the current WAL position is security-sensitive information,
> > we're doing something wrong.

I really don't see the downside to limiting who can see that
information. I meant to mention it in my email last night with the
patch allowing the GRANT system to work for other functions, but I added
the functions suggested by Michael to the list of ones which don't have
the default ACL of 'execute to PUBLIC' to that set.

> > But I don't want to just give up either. One option is to make this
> > controllable on a per-table basis, as Amit suggested. Then we could always
> > disable it for pg_authid, add a suitable warning to the docs, and let the
> > DBA enable/disable it for other tables. It's a bit of a cop-out, but would
> > fix the immediate problem.
>
> I think it's a fairly narrow attack vector. As long as we document it
> clearly, and make it easy enough to turn it off, I think that's definitely
> enough. Most people will not care at all, I'm sure - but we need to cater
> to those that do.

I agree that it's something to document, but I don't think it's sensible
to have the default be "at risk". That said, as long as there's a way
to restrict access to these functions (without having to fight with the
system on upgrades, etc, to have that be preserved..) then I'm not going
to push too hard about the default. We need a proper "hardening"
guide anyway, this would just need to be included in that documentation.

> I think we could probably even get away with just documenting the risk and
> having people turn off the compression *completely* if they care about it,
> but if we can do it at a table level, that's obviously a lot better.

I *really* don't like the idea that the "fix" for such an information
disclosure risk is to completely disable an extremely useful feature.
In fact, I find the suggestion of it rather ridiculous.

I do like the idea of being able to control this on a per-table basis
as that's a useful feature, but that's completely independent from this
concern.

Thanks!

Stephen