Re: Goodbye pg_pltemplate, hello trusted extensions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Goodbye pg_pltemplate, hello trusted extensions
Date: 2018-04-27 21:15:50
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stas Kelvich 2018-04-27 21:36:16 FinishPreparedTransaction missing HOLD_INTERRUPTS section
Previous Message Andres Freund 2018-04-27 20:58:44 Re: Goodbye pg_pltemplate, hello trusted extensions