Re: Removing pg_pltemplate and creating "trustable" extensions

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Removing pg_pltemplate and creating "trustable" extensions
Date: 2020-01-07 18:55:50
Message-ID: CA+Tgmob1cEG=CHnUnryBKdpLhg+jxXH0ZRXpF2OGX1WU8hgQvQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 7, 2020 at 1:17 PM Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> Why would it be trusted if it's $SCARY_EXTENSION ...? Why are we trying
> to punt on solving for that question by installing a much more
> complicated system here than is really necessary, just to avoid having
> to make that decision?

I'm not convinced that whether or not something is trusted is an
altogether objective question. For instance, postgres_fdw probably
doesn't let you become the superuser, unless it has bugs. But it does
let you make network connections originating from the database host,
and somebody might reasonably want to restrict that in a
security-sensitive environment. But the same user might be totally OK
with a particular database owner installing citext.

> If these functions were to just be put into core (as many really should
> be...), instead of being out in contrib, this whole issue also wouldn't
> exist and everyone would be able to use the functions (at least, those
> that we decide are safe for users to directly use- and with appropriate
> privilege access over ones that aren't), without any "the superuser must
> approve of this explicitly after installation" fuss.

Well, I don't agree with the idea of moving everything into core, but
I think a good solution to the problem at hand will reduce the fuss
while allowing superusers to retain some control.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2020-01-07 19:17:15 Re: RFC: seccomp-bpf support
Previous Message Alexander Korotkov 2020-01-07 18:54:35 Re: [PATCH] Atomic pgrename on Windows