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

Greetings,

* Robert Haas (robertmhaas@gmail.com) wrote:
> On Mon, Jan 6, 2020 at 6:56 PM Stephen Frost <sfrost@snowman.net> wrote:
> > The first is this- ANYONE can create an extension in the system today,
> > if it's marked as superuser=false.  If anything, it seems like that's
> > probably too loose- certainly based on your contention that ONLY
> > superusers should wield such a power and that letting anyone else do so
> > is a right that a superuser must explicitly grant.
>
> I don't think this argument makes any sense. Sure, anyone can create
> an extension with superuser=false, but so what? From a security point
> of view, when you create such an extension, you are using your own
> privileges to do things that you could do anyway. The interesting case
> is creating an extension that requires superuser privileges, probably
> because it's going to call C functions. The superuser can and must
> have the last word regarding who is allowed to do such things, because
> the superuser is equivalent to the OS user and any other user of the
> system is not. The "tenants" of the database system can't be allowed
> to use it for things which the "owner" does not wish to permit.

What's the security issue from installing a trusted extension?

> On Mon, Jan 6, 2020 at 6:26 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > If we were willing to break backwards compatibility, what I'd prefer
> > is to just have the grantable role, and to say that you have to grant
> > that to DB owners if you want them to be able to install PLs.  I'm
> > not sure how loud the howls would be if we did that, but it'd be a
> > lot cleaner than any of these other ideas.
>
> That seems like a fine idea. Then the superuser has ultimate control,
> and can decide which database owners they want to trust, and whether
> they'd like the database owners to be able to subdelegate those
> permissions. The only thing it doesn't do is give any control over
> exactly which extensions can be installed by non-superusers, which
> would be a really nice thing to have, especially if we're going to
> significant expand the list of trusted extensions (something that I
> think is, overall, quite a good idea). I accept Tom's argument that he
> isn't obliged to add every related feature somebody might want just
> because he's doing some work in this area, but not his contention that
> the demand for such a feature is entirely hypothetical and the
> suggestion that perhaps nobody will care anyway. I expect the reaction
> to be along the lines of "hey, it's great that we can let DB owners do
> this now, but it's really too bad that I can't blacklist
> $SCARY_EXTENSION". I don't think that we'll be better off if this
> entire proposal gets voted down for lack of that capability, but I
> think it would be a really good thing to add.

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?

If the extension is trusted, then there isn't a security issue with it,
and it isn't scary, by definition, imv, which negates these arguments
about making the right to install it have to be hand delegated by a
superuser and needing a system for managing who is allowed to install
what extension.

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.

> FWIW, I don't really buy the argument that you can adjust the
> extension control files to get out from under this problem.
> Technically, that is true. But in practice, the extension control
> files are provided by your packager, and you don't want to modify them
> because then your packaging system will get grumpy with you. While
> it's reasonable for the packaging to provide a tentative answer to the
> question of what should be trusted, trust is ultimately a matter of
> local policy, and that policy should be configured someplace that's
> not managed by RPM.

This I tend to agree with- hacking around with control files or other
files installed with extensions from RPMs isn't a great plan.

A possible alternative would be to have a *new* configuration file (not
part of the GUC system) which admins could hack up to specify who should
be allowed to install what extension.  Or we make that a catalog table
instead because, well, such things should probably be in the database
where we can have dependency management and validity checking...

On the other hand, having individual packages for different extensions
is a pretty handy way of letting an administrator decide if they want
that extension to be installed on their system or not.  That's a pain
for contrib because, really, all of those should really just be in core,
or not included if we aren't confident that they're safe to use.

Thanks,

Stephen