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
-
Remove support for upgrading extensions from "unpackaged" state.
- 70a7732007bc 13.0 landed
-
Mark some contrib modules as "trusted".
- eb67623c965b 13.0 landed
-
Invent "trusted" extensions, and remove the pg_pltemplate catalog.
- 50fc694e4374 13.0 cited