Re: PlPython

Поиск
Список
Период
Сортировка
От Doug McNaught
Тема Re: PlPython
Дата
Msg-id m3r85e1ckh.fsf@varsoon.wireboard.com
обсуждение исходный текст
Ответ на Re: PlPython  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: PlPython  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
Tom Lane <tgl@sss.pgh.pa.us> writes:

> elein <elein@varlena.com> writes:
> > Exactly what functions are prohibited (or acceptable)
> > for a pl language in PostgreSQL to become trusted?
> > Is the exact criteria list documented somewhere?
>
> We don't have a formal definition, but I'd say a minimum requirement
> is that a function written in a trusted PL language cannot cause any
> outside-the-database actions to be attempted by the backend (such as
> trying to read or write any files in the server's filesystem).  A
> trusted-PL language should be able to define arbitrary self-contained
> computations (arithmetic, pattern-matching, or what have you), and it
> should be able to access the database at the same level as regular
> SQL commands.  It should not be able to bypass the SQL abstractions nor
> execute any OS-level operations using the postgres user's privileges.

What about making network connections?  That seems less harmful than
filesystem access, and certainly could have legitimate uses.

-Doug

В списке pgsql-general по дате отправления:

Предыдущее
От: Tony Grant
Дата:
Сообщение: Re: Redhat's "enhancements" to PG
Следующее
От: Jan Wieck
Дата:
Сообщение: Re: How many fields in a table are too many