Re: PlPython

Поиск
Список
Период
Сортировка
От elein
Тема Re: PlPython
Дата
Msg-id 200306271506.38598.elein@varlena.com
обсуждение исходный текст
Ответ на Re: PlPython  (Karsten Hilbert <Karsten.Hilbert@gmx.net>)
Ответы Re: PlPython  ("scott.marlowe" <scott.marlowe@ihs.com>)
Re: PlPython  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general

Perhaps this should be asked on the interfaces list, but...
Exactly what functions are prohibited (or acceptable)
for a pl language in PostgreSQL to become trusted?

Is the exact criteria list documented somewhere?

Since C is wide open, why is it considered trusted,
or is it?  Or are some C calls disallowed by the
function manager (this was what we did at informix,
we also enforced permissions carefully (after showing
how easy it was to break things :-) ).

My guess of the list would be:
    1. No or a restricted set of OS calls
        (what would be the restricted set?
         The set Keith removed?)
    2. No file system operations or strongly
       enforced permissions on file system operations.

Elein

On Thursday 26 June 2003 11:48, Karsten Hilbert wrote:
> >>Now that the rexec code is gone, it MUST be marked untrusted --- this is
> >>not a question for debate.  Installing it as trusted would be a security
> >>hole.
> >
> > That means that there is something else untrusted in PLPython,
> > what is this?
> Well, basically everything else.
>
> You are getting this backwards. Making Python a *trusted*
> language *requires* something like rexec. Since we don't have
> rexec anymore (it never was much good, apparently) we cannot
> make Python trusted. Hence we must make it untrusted to keep
> it in at all.
>
> The point here is not whether we trust the rest of Python but
> whether we have something (like rexec) that restricts the
> standard Python. Only if we have that do we define a language
> as "trusted".
>
> Things would be different, of course, if an entire language
> was restricted by nature. That would be a candidate for a
> trusted language without needing specific add-on execution
> restriction.
>
> Karsten
> --
> GPG key ID E4071346 @ wwwkeys.pgp.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>
>

--
=============================================================
elein@varlena.com     Database Consulting     www.varlena.com
PostgreSQL General Bits    http:/www.varlena.com/GeneralBits/
   "Free your mind the rest will follow" -- en vogue


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

Предыдущее
От: Erik Price
Дата:
Сообщение: Re: dropping sequences
Следующее
От: Guy Fraser
Дата:
Сообщение: Re: Redhat's "enhancements" to PG