Re: PlPython

From: Doug McNaught <doug(at)mcnaught(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: elein(at)varlena(dot)com, Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net>, pgsql-general(at)postgresql(dot)org
Subject: Re: PlPython
Date: 2003-06-28 14:50:06
Message-ID: m3r85e1ckh.fsf@varsoon.wireboard.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> elein <elein(at)varlena(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jan Wieck 2003-06-28 15:05:51 Re: How many fields in a table are too many
Previous Message Tony Grant 2003-06-28 05:53:00 Re: Redhat's "enhancements" to PG

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-06-28 15:21:35 Re: PlPython
Previous Message Jan Wieck 2003-06-28 14:22:33 Re: Two weeks to feature freeze