Andres Freund <andres@anarazel.de> writes:
> On 2018-04-27 16:34:04 -0400, Tom Lane wrote:
>> So I thought for awhile about how to deal with that, and eventually
>> decided that really what we need to do is solve this as part of the
>> extension mechanism, not CREATE LANGUAGE per se. What I'm imagining
>> is that we add new option(s) to extension control files that allow
>> specifying that the extension's script is run as a different user
>> than the user invoking CREATE EXTENSION.
> I don't think the extension control file is really the best place for
> such policy decisions. An extension script can be safe, but not a great
> idea for some installations nevertheless. I don't think it'd be a good
> idea to require site operators to modify extension control files to tune
> trustedness. I think it might be reasonable to have control file state
> whether they *may* be set as trustable, but then the decision which
> extensions a specific cluster determines as safe needs to be made in a
> catalog or configuration file.
Well, the same could be said about the existing contents of pg_pltemplate,
but how many sites do you know that editorialize on that? I think for
the vast majority of sites, the DBA just decides whether to install an
extension (into the extension/library directories) and that's plenty of
control. Second-guessing the extension author about whether unprivileged
users should be allowed to install an extension seems like a very niche
requirement. On the other hand, *lots* of people have wished for being
able to install, say, hstore into a particular DB without having to be
superuser, once the DBA has made that extension available.
I will agree that having a global disable switch in postgresql.conf or
someplace might be worth doing. I don't think very many people would
use per-extension configuration overrides.
regards, tom lane