Re: Marking some contrib modules as trusted extensions

Dean Rasheed <dean.a.rasheed@gmail.com>

From: Dean Rasheed <dean.a.rasheed@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Julien Rouhaud <rjuju123@gmail.com>, Darafei Komяpa Praliaskouski <me@komzpa.net>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2020-01-31T09:40:32Z
Lists: pgsql-hackers
On Wed, 29 Jan 2020 at 21:39, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> >>> pg_stat_statements
>
> Mmm, I'm not convinced --- the ability to see what statements are being
> executed in other sessions (even other databases) is something that
> paranoid installations might not be so happy about.  Our previous
> discussions about what privilege level is needed to look at
> pg_stat_statements info were all made against a background assumption
> that you needed some extra privilege to set up the view in the first
> place.  I think that would need another look or two before being
> comfortable that we're not shifting the goal posts too far.
>
> The bigger picture here is that I don't want to get push-back that
> we've broken somebody's security posture by marking too many extensions
> trusted.  So for anything where there's any question about security
> implications, we should err in the conservative direction of leaving
> it untrusted.
>

+1

I wonder if the same could be said about pgrowlocks.

Regards,
Dean



Commits

  1. Remove support for upgrading extensions from "unpackaged" state.

  2. Mark some contrib modules as "trusted".

  3. Invent "trusted" extensions, and remove the pg_pltemplate catalog.