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

From Joe Conway
Subject Re: exposing pg_controldata and pg_config as functions
Date
Msg-id 56C50630.5050707@joeconway.com
Whole thread Raw
In response to Re: exposing pg_controldata and pg_config as functions  (Josh berkus <josh@agliodbs.com>)
List pgsql-hackers
On 02/17/2016 03:34 PM, Josh berkus wrote:
> On 02/17/2016 03:02 PM, Tom Lane wrote:
>> Joe Conway <mail@joeconway.com> writes:
>>> On 02/17/2016 02:14 PM, Tom Lane wrote:
>>>> I thought we'd agreed on requiring superuser access for this function.
>>>> I concur that letting just anyone see the config data is inappropriate.
>>
>>> It does not let anyone see config data out of the box:
>>
>>> + CREATE VIEW pg_config AS
>>> +     SELECT * FROM pg_config();
>>> +
>>> + REVOKE ALL on pg_config FROM PUBLIC;
>>> + REVOKE EXECUTE ON FUNCTION pg_config() FROM PUBLIC;
>>
>> Ah, that's fine.  I'd looked for a superuser() check and not seen one,
>> but letting the SQL permissions system handle it seems good enough.
>
> What I like about this is that if I want to expose it to a
> non-superuser, I can just do a GRANT instead of needing to write a
> security definer view.

Which was my reason for doing it this way, although that GRANT will not
get preserved by pg_dump currently. Stephen Frost is working on a patch
to change/fix that though (see the "Additional role attributes &&
superuser review" thread), which I believe he intends to get done RSN
and into 9.6.

Joe



--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Restructuring Paths to allow per-Path targetlist info
Next
From: Michael Paquier
Date:
Subject: Re: extend pgbench expressions with functions