Re: Removing pg_pltemplate and creating "trustable" extensions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Removing pg_pltemplate and creating "trustable" extensions
Date
Msg-id 12039.1578602021@sss.pgh.pa.us
Whole thread Raw
In response to Re: Removing pg_pltemplate and creating "trustable" extensions  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Removing pg_pltemplate and creating "trustable" extensions  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> I am not particularly concerned about that backwards compatibility issue
> and I don’t intend to base my argument on it, but I would use that case to
> point out that we have long had the ability to install trusted C functions
> into the backend as a DB owner, without complaint from either users or
> security pedants,

Right, which is why my patch proposes generalizing that feature for
trusted PLs into a general feature for other extensions.  I'd be
much leerier of that if we'd had any pushback on it for trusted PLs.

> ... and that backs up my position that we are setting up this
> privilege at the wrong level by using a default role which a superuser must
> grant independently from DB ownership.

Don't see how this follows.  It's somewhat accidental I think that
the existing behavior is tied to DB ownership.  That's just because
at the time, that's the only sort of privilege we had that seemed
intermediate between superuser and Joe User.  If we were designing
the behavior today, with default roles already a done deal for
handing out possibly-dangerous privileges, I think there's no
question that we'd be setting up this privilege as a default role
rather than tying it to DB ownership.  We don't make DB ownership
a prerequisite to creating other sorts of functions, yet other
functions can be just as dangerous in some cases as C functions.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Coding in WalSndWaitForWal
Next
From: Dent John
Date:
Subject: Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from aREFCURSOR