Re: exposing pg_controldata and pg_config as functions
От | Joe Conway |
---|---|
Тема | Re: exposing pg_controldata and pg_config as functions |
Дата | |
Msg-id | 56C50630.5050707@joeconway.com обсуждение исходный текст |
Ответ на | Re: exposing pg_controldata and pg_config as functions (Josh berkus <josh@agliodbs.com>) |
Список | 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 по дате отправления: