Re: Removing pg_pltemplate and creating "trustable" extensions - Mailing list pgsql-hackers

Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> >> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> >>> 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).
>
> > Two things- first, this doesn't actually cover everything that the
> > proposed GUCs do- specifically, the proposed GUCs give you a way to
> > limit what specific extensions are allowed to be installed, and by whom.
> > Moving to a GRANT-based system removes the extension specificity and
> > leaves with just "is user X allowed to install extensions".
>
> True.  But do we care?  We did not have that flexibility before, either.

I'm not 100% sure that we do, but I wanted to mention it as a
difference.  Certainly there have previously been suggestions of having
a 'whitelist' similar to what you initially proposed, that are
extensions which non-superusers are allowed to install.

> I'd still keep the "trustable" property (probably renamed to "trusted"
> for simplicity) for extensions, so in the worst case, an admin could
> edit extension control files to add or remove the per-extension flag.

At a high level, I agree with the idea of an extension being able to be
marked as one that's "trusted" or not, but we would also need to come up
with exactly what that means for it to really have value, and I don't
think we've really done that yet.

> > Second,
> > this approach is requiring that a user who is allowed to create
> > extensions must also be allowed to create schemas on the database in
> > question.
>
> That doesn't seem like a big objection from here.  We could fix it
> by making a separate privilege bit, but I doubt that it's worth using
> up one of our limited set of spare bits for.

I do not agree that we should just shift to using default roles instead
of adding new options to GRANT because of an entirely internal
implementation detail that we could fix (and should, as I've said for
probably 10 years now...).

> >> 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?
>
> > If we just created another one, wouldn't that remove the need to have a
> > database role?
>
> No, because then being DB owner would be alone be enough to let you
> install extensions (since as owner, you could certainly grant yourself
> all privileges on the DB, even if this were somehow not the default).
> We'd have to mangle GRANT's behavior to avoid that, and I don't think
> we should.  Nor do I think that DB ownership ought to be enough
> privilege by itself.

Really?  Why do you think that DB ownership shouldn't be enough for
this, for trusted extensions?

I agree that we don't want to mangle GRANT's behavior, at all, for this.

> >> 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".
>
> > With this, you couldn't have a user who is able to create extensions but
> > not able to create schemas though.  That kind of combining of privileges
> > together really goes against the general principle of 'least privilege',
> > unless the action associated with one necessairly requires the other,
> > but I don't believe that's the case here.
>
> A point here is that many extensions involve creating their own schemas
> anyway.  Also, the ability to "relocate" an extension to a different
> schema is pretty meaningless if you can't create a schema to put it in.

What extensions require creating their own schema?  Every single
extension that's in contrib can be installed into the public schema
(concurrently, even) except for two hacks- plpgsql and adminpack, and
those go into pg_catalog for historical reasons more than anything else.

Creating a schema is an option for extensions but it isn't a
requirement.  I agree that you need the ability to create schemas if you
want to relocate one, but that's like needing SELECT to do an UPDATE
without a WHERE clause.  I also don't know that extension relocation is
really something that's commonly done.

> If I thought that there were a use-case for letting someone create
> extensions but not schemas, I'd be more eager to invent a new bit.
> But I'm having a *really* hard time envisioning a live use-case
> for that.  Granting extension-creation ability requires a whole lot
> more trust in the grantee than the ability to make new schemas
> (which, in themselves, have about zero impact on anybody else).

The idea of 'least privilege' isn't "well, I'm gonna grant you this
other thing that you don't actually need, just because I trust you with
this privilege that you do need."

Thanks,

Stephen