Return-Path: postarch
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA29459; Tue, 19 May 92 08:57:21 -0700
Message-Id: <9205191557.AA29459@postgres.Berkeley.EDU>
From: postarch (Postgres Mailing Archive)
Subject: Re: security & dynamic loader
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
Reply-To: mer@postgres.berkeley.edu
In-Reply-To: Your message of "Wed, 13 May 92 11:32:23 +0700."
             <9205131035.AA10503@postgres.Berkeley.EDU> 
Date: Tue, 19 May 92 08:57:09 PDT

you write:

> I just found another security problem in postgres. Using the
> dynamic loader one can write an adt the performs something like
> system("xterm") and you will get a shell under postgres rights.
> The dynamic loader links everything that is readable.
> 
> I just put some code in the dynamic loader, so that the .o
> files must be owned by the backend himself. But this is not an
> optimal solution since everyone developing an adt must install
> it under postgres rights.
> 
> Any suggestions?

Dynamic loading into a dbms is new territory for which there isn't
really a good model for the protocol.  It is clear that in the real
world you are only going to allow "trusted" developers the priviledge
of defining adts due to compromised security.  For you the only choices
are restricting the priviledge or making frequent backups of 'important'
data.

One other option that the dbms *should* provide is the ability to execute
'untrusted' functions in a separate address space (under restricted
permissions) via rpc's.  The problem with this approach is that it is
(in the words of a famous database professor) slower than molasses.


Jeff Meredith
mer@postgres.berkeley.edu