From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: pgsql-hackers@lists.postgresql.org, Stephen Frost <sfrost@snowman.net>
Subject: Re: Removing pg_pltemplate and creating "trustable" extensions
Date: Wed, 06 Nov 2019 10:06:42 -0500
Message-ID: <27727.1573052802@sss.pgh.pa.us> (raw)
In-Reply-To: <c15c0f58-79a9-4051-1f43-8fc06564df69@2ndquadrant.com>
References: <5889.1566415762@sss.pgh.pa.us>
<c15c0f58-79a9-4051-1f43-8fc06564df69@2ndquadrant.com>
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 2019-08-21 21:29, Tom Lane wrote:
>> Patch 0001 below addresses this problem by inventing a concept of
>> "trustable" (not necessarily trusted) extensions. An extension that
>> would normally require superuser permissions (e.g., because it creates
>> C functions) can now be installed by a non-superuser if (a) it is
>> marked trustable in the extension's control file, AND (b) it is
>> listed as trusted in one of two new GUCs, trusted_extensions_dba and
>> trusted_extensions_anyone.
> I think this overall direction is good. I'm not so fond of the interfaces.
> Using GUCs to control some of this creates yet another place where
> permission information is kept, and with it questions about how to get
> to it, how to edit it, or to back it up and restore it, etc. Also,
> list-based parameters are particularly hard to manage by automated
> tools. I think we can do this within the existing permission system,
> for example with pre-defined roles (for example, GRANT
> pg_create_trusted_extension ...). Also, CREATE EXTENSION should somehow
> be controlled by the CREATE privilege on the containing database, so a
> separate setting for database owner vs. regular user might not be
> necessary. Regular users would need both the role membership (given by
> the overall superuser) and the privilege within the database (given by
> the database owner).
Hm. In principle I'm okay with the idea of having a predefined role
or two for extension installation. I think though that we could not
easily make that design emulate the current behavior, wherein database
owners automatically have the ability to install trusted PLs. The
superuser would have to take the additional step of granting them a
role to let them do that. Maybe that's just fine --- from some
angles it could be seen as an improvement --- but it is an
incompatibility. Anybody have a problem with that?
Do we need more than one level of extension trust-ability (and more
than one predefined role to go with that)? Assuming that we go ahead
and mark all the safe-looking contrib modules as trustable, granting
"pg_install_extensions" or whatever we call it would then give a DB
owner more privilege than just the ability to install trusted PLs.
But maybe that's fine too.
I agree with the idea of requiring a DB-level privilege as well as
the overall role. Is it okay to re-use the CREATE privilege (which
today only allows for CREATE SCHEMA), or do we need another one?
I think re-using CREATE is probably all right, since it would only be
useful for this purpose to users who also have "pg_install_extensions".
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, peter.eisentraut@2ndquadrant.com, sfrost@snowman.net
Subject: Re: Removing pg_pltemplate and creating "trustable" extensions
In-Reply-To: <27727.1573052802@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox