| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Proposal: knowing detail of config files via SQL |
| Date: | 2015-03-02 21:47:01 |
| Message-ID: | CA+TgmobnmuJdeO3H4x-mkC9ZK6K3-wroqRQx=WFSpOiT_LbcXg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Feb 28, 2015 at 12:27 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> While this generally "works", the usual expectation is that functions
> that should be superuser-only have a check in the function rather than
> depending on the execute privilege. I'm certainly happy to debate the
> merits of that approach, but for the purposes of this patch, I'd suggest
> you stick an if (!superuser()) ereport("must be superuser") into the
> function itself and not work about setting the correct permissions on
> it.
-1. If that policy exists at all, it's a BAD policy, because it
prevents users from changing the permissions using DDL. I think the
superuser check should be inside the function, when, for example, it
masks some of the output data depending on the user's permissions.
But I see little virtue in handicapping an attempt by a superuser to
grant SELECT rights on pg_file_settings.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2015-03-02 21:52:37 | Re: POLA violation with \c service= |
| Previous Message | Andres Freund | 2015-03-02 21:45:28 | Re: autogenerated column names + views are a dump hazard |