I took another look at this patch, and I still can't persuade
myself that a good case has been made for it. There are too
many scenarios where pg_manage_extensions would be a security
problem and too few where it seems to really improve manageability.
As an example, it was asserted upthread that it's not a security
problem to let someone install plpython3u, because they still
couldn't create any plpython3u functions unless they were
superuser. Well, fine, but then what's the point of installing
it? If there is someone around with enough privilege to use
plpython3u, that person can install it first.
I also don't buy the argument that service providers would be
unwilling to set the "trusted" flag on extensions that for whatever
reason they are willing to let be installed by non-superusers.
This thread is full of (unsupported) assertions that those same
providers are making far more invasive changes to the PG code base
to achieve their desired results.
Robert Haas <robertmhaas@gmail.com> writes:
> I agree, but I also don't want the security decisions that the core
> project takes to become irrelevant in practice. It seems like what's
> starting to happen is that all of the cloud providers end up finding
> the same issues and working around them in very similar ways and they
> don't do anything in PostgreSQL itself, I guess because that would
> require winning an argument on the mailing list.
It would at least require showing up on the mailing list.
None of the assertions made in this thread about what cloud
providers are doing have been supported by a whit of evidence
about that.
What I'm wishing for is that some of the providers would show up here
and provide specific details (preferably patches) about what they are
changing and why. Then we could have an informed discussion about
how to make their lives less painful in the future. Right now
I think we're guessing --- I certainly am. Maybe some of the people
on this thread have access to such details, but they aren't sharing.
regards, tom lane
