Re: exposing pg_controldata and pg_config as functions - Mailing list pgsql-hackers

From Andres Freund
Subject Re: exposing pg_controldata and pg_config as functions
Date
Msg-id 20160118094340.GQ10941@awork2.anarazel.de
Whole thread Raw
In response to Re: exposing pg_controldata and pg_config as functions  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: exposing pg_controldata and pg_config as functions  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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?

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

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Gilles Darold
Date:
Subject: Re: Optimizer questions
Next
From: Artur Zakirov
Date:
Subject: Re: Fuzzy substring searching with the pg_trgm extension