From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: exposing pg_controldata and pg_config as functions |
Date: | 2016-01-18 09:43:40 |
Message-ID: | 20160118094340.GQ10941@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Shulgin, Oleksandr | 2016-01-18 09:46:20 | Re: More stable query plans via more predictable column statistics |
Previous Message | Gilles Darold | 2016-01-18 09:32:03 | Re: Optimizer questions |