* Fujii Masao (masao.fujii@gmail.com) wrote:
> On Tue, Jul 7, 2015 at 10:31 PM, Stephen Frost <sfrost@snowman.net> wrote:
> > 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.
>
> A user can very easily limit such information by not enabling wal_compression.
> No need to restrict the usage of WAL location functions.
> Of course, as Michael suggested, we need to make the parameter SUSET
> so that only superuser can change the setting, though.
I agree with making it SUSET, but that doesn't address the issue.
> Or you're concerned about the case where a careless user enables
> wal_compression unexpectedly even though he or she thinks the risk
> very serious? Yes, in this case, non-superuser may be able to exploit
> the vulnerability by seeing the WAL position. But there are many cases
> where improper setting causes unwanted result. So I'm not sure why
> we need to treat wal_compression so special.
If I understand correctly, and perhaps I don't, this is an optimization
which is an improvment in a large number of cases, to the point where we
should almost certainly have it enabled by default. Having an
exploitable hole in an optimization tunable is akin to having -O3 in gcc
remove bounds checking.
What is the postgresql.conf entry going to look like?
#wal_compression = off # Do not enable, security risk
And this is all to preserve having the WAL location information be world
readable? I do not understand how that makes sense.
Further, I'm very curious what other optimization tunables we have which
open security holes in PG. This is not the same as making untrusted
users superusers or creating poorly written and exploitable security
definer functions.
Thanks,
Stephen