On Mon, Jan 18, 2016 at 4:43 AM, Andres Freund <andres@anarazel.de> wrote:
> On 2016-01-18 10:18:34 +0900, Michael Paquier wrote:
>> We are trying to hide away from non-superusers WAL-related information
>> in system views and system function, that's my point to do the same
>> here.
>
> We are? pg_current_xlog_insert_location(), pg_current_xlog_location(),
> pg_is_xlog_replay_paused(), pg_stat_bgwriter ... are all non-superuser?
Yeah. There's certainly no need for the WAL positions reported by
pg_controldata to be any more restricted than other functions that
give away information about WAL position. We had some discussion
about restricting WAL position information in general due to possible
information leakage, and if we do that, then perhaps this should be
similarly restricted. Presumably vulnerabilities here would be harder
to exploit because the values change much less frequently, so if you
are trying to learn something the rate at which you can glean
information will be much lower. But maybe we should put the same
restrictions on all of it.
>> For the data of pg_control, it seems to me that this can give
>> away to any authorized users hints regarding the way Postgres is
>> built, perhaps letting people know for example which Linux
>> distribution is used and which flavor of Postgres is used (we already
>> give away some information with version() but that's different than
>> the libraries this is linking to), so an attacker may be able to take
>> advantage of that to do attacks on potentially outdated packages? And
>> I would think that many users are actually going to revoke the access
>> of those functions to public if we are going to make them
>> world-visible. It is easier as well to restrict things first, and then
>> relax if necessary, than the opposite as well.
>
> Meh, that seems pretty far into pseudo security arguments.
Yeah, I really don't see anything in the pg_controldata output that
looks sensitive. The WAL locations are the closest of anything,
AFAICS.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company