Re: Removing pg_pltemplate and creating "trustable" extensions

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Removing pg_pltemplate and creating "trustable" extensions
Дата
Msg-id 12039.1578602021@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Removing pg_pltemplate and creating "trustable" extensions  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: Removing pg_pltemplate and creating "trustable" extensions
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Coding in WalSndWaitForWal
Следующее
От: Dent John
Дата:
Сообщение: Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from aREFCURSOR