Re: Removing pg_pltemplate and creating "trustable" extensions

Greetings,

* Robert Haas (robertmhaas@gmail.com) wrote:
> On Thu, Jan 9, 2020 at 10:09 AM Stephen Frost <sfrost@snowman.net> wrote:
> > [ wall of text ]

This really isn't helpful.

> I don't see anything in here I really disagree with, but nor do I
> understand why any of it means that giving superusers the ability to
> customize which extensions are database-owner-installable would be a
> bad thing.

Alright, I think there's definitely something we need to sort through.

If you agree that the approach I advocated means less code for hosting
providers to have to change in their fork, and that they don't want to
give users superuser, and that they want non-superusers to be able to
install extensions, and that they really don't want to modify things
post-install, then I don't get why you're against the DB-level privilege
that I've been advocating for except that it's "not as customizable."

Are you saying that in order to have something here that we must make it
so that a superuser is able to specifiy, individually, which extensions
can be installed by which users?  You keep coming back to this point of
saying that you want this to be 'customizable' but I really don't see
any justification for the level of customization you're asking for- but
I see an awful lot of work involved.  When there's a lot of work
involved for a use-case that no one is actually asking for, I'm really
skeptical.  The use-cases that you've presented, at least thus far,
certainly haven't swayed me into thinking that you're right that there's
a justifiable use-case here for this level of complicated privileges.

I'm also not convinced that such a design would even be practical- we
don't know all of the extensions that a given PG install will be able to
have when it's first installed.  If postgis isn't on the filesystem when
someone installs PG, how do I, as a superuser, say that $user is allowed
to install postgis?  Or do we always have to have this two-step "install
on filesystem", "grant privs to $user to install" process?  What if that
extension is then uninstalled from the filesystem?  Do we have to clean
up the GRANT that was done?

> > > I don't think changing what's in contrib helps much. Even if we rm
> > > -rf'd it, there's the same problem with out-of-core extensions. Joe
> > > Extensionman may think his extension ought to be trusted, and package
> > > it as such, but Paula Skepticaldba is entitled to think Joe's view of
> > > the security risks originating from his code is overly rosy.
> >
> > Out of core extensions have to get installed on to the system though,
> > they don't just show up magically, and lots and lots of folks out there
> > from corporate infrastructure groups to hosting providers have got lots
> > of experience with deciding what they'll allow to be installed on a
> > system and what they won't, what repositories of code they'll trust and
> > which they won't.
>
> You seem to be ignoring the actual point of that example, which is
> that someone may want to install the extension but have a different
> view than the packager about whether it should be trusted.

Why would someone want to install something that isn't trusted?  You're
implying that's what is happening here, but it doesn't make any sense to
me and without it making sense I can't agree that it's a sensible enough
use-case to demand a lot of work be put into it.

> You seem to think that that hosting providers and system
> administrators will be thrilled to accept the judgement of developers
> about which extensions should be trusted in their environment. Great!

Huh?  Hosting providers are the ones that choose what gets installed on
the filesystem, certainly not developers, so I am baffled how you came
to the conclusion that I'm suggesting administrators are trusting the
judgement of developers.  That's just not at all the case.

> Evidently you disagree, and that's fine, even if I don't understand
> why. Given some of the development projects you've done in the past, I
> find it extremely surprising to here you now taking the position that
> fine-grained security controls are, in this case, unnecessary and
> useless, but you don't have to like it everywhere just because you
> like it for some things.

I'm all for fine-grained control- where it makes sense.  I'm still
*very* much of the opinion that we should be able to let DB owners and
schema owners control what kind of objects users are allowed to create
in their DBs/schemas.  I want a "GRANT CREATE FUNCTION ON SCHEMA mine TO
you;" ability.  I'm not clamouring for a way to say "GRANT CREATE
THISSPECIFICFUNCTION ON SCHEMA mine TO you;" or something like "GRANT
CREATE FUNCTION MATCHING REGEXP 'abc_*' ON SCHEMA mine TO you;".

In the end, superusers are, in fact, the ones who grant out ALL access,
the question is what level of access they want to grant out and to whom.
When it comes to trusted objects, we've historically said that it's the
DB owner who gets to say who can grant out that access and all I'm
trying to argue for is that we continue with that.

Thanks,

Stephen