Re: Marking some contrib modules as trusted extensions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: Julien Rouhaud <rjuju123(at)gmail(dot)com>, Darafei Komяpa Praliaskouski <me(at)komzpa(dot)net>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Marking some contrib modules as trusted extensions
Date: 2020-01-31 15:13:19
Message-ID: 23117.1580483599@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> On Wed, 29 Jan 2020 at 21:39, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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.

> I wonder if the same could be said about pgrowlocks.

Good point. I had figured it was probably OK given that it's
analogous to the pg_locks view (which is unrestricted AFAIR),
and that it already has some restrictions on what you can see.
I'd have no hesitation about dropping it off this list though,
since it's probably not used that much and it could also be seen
as exposing internals.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2020-01-31 15:59:18 Re: Use compiler intrinsics for bit ops in hash
Previous Message Alvaro Herrera 2020-01-31 14:47:57 Re: standby apply lag on inactive servers