Re: exposing pg_controldata and pg_config as functions

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Joe Conway <mail(at)joeconway(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, 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-16 23:46:36
Message-ID: CAB7nPqTAzVAo3Q7K=vMpZZEWJfM6M_H1farz6v2Qoid=_Tagyw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jan 17, 2016 at 12:27 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Jan 16, 2016, at 9:08 AM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote:
>> Just forgot to mention that those new functions should be superuser-only.
>
> I think nobody should ever say this without explaining why. Superuser restrictions are necessary in some cases, but the fewer of them we have, the better.

The pg_config functions are giving away information about the system
itself, isn't that potentially sensible? The pg_controdata ones show
up information about checkpoint, recovery etc. There are a couple of
fields that could be made completely visible, like the information
defined when running initdb or how the code is compiled like block
size (not the system ID), but we surely do not want to give away
checkpoint and recovery information.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-01-16 23:48:46 Re: exposing pg_controldata and pg_config as functions
Previous Message Michael Paquier 2016-01-16 23:42:56 Re: [GENERAL] Re: [BUGS] about test_parser installation failure problem(PostgreSQL in 9.5.0)?