Re: Specification for Trusted PLs? - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: Specification for Trusted PLs?
Date
Msg-id 4BF9E3B5.4090800@postnewspapers.com.au
Whole thread Raw
In response to Re: Specification for Trusted PLs?  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
On 21/05/10 23:55, Josh Berkus wrote:
> So, here's a working definition:
>
> 1) cannot directly read or write files on the server.

It must also prevent PL-user-level access to file descriptors already 
open by the backend. That's implicitly covered in the above, but should 
probably be explicit.

> 2) cannot bind network ports
> 3) uses only the SPI interface to interact with postgresql tables etc.
> 4) does any logging only using elog to the postgres log

5) Cannot dynamically load shared libraries from user-supplied locations

(eg in Python, 'import' of a module that had a .so component would be 
blocked unless it was in the core module path)

> a) it seems like there should be some kind of restriction on access to
> memory, but I'm not clear on how that would be defined.

Like:

5) Has no way to directly access backend memory, ie doesn't have 
PL-user-accessible pointers or user access to any C-level calls that 
take/return them. Data structures containing pointers must be opaque to 
the PL user.

The idea being that if you have no access to C APIs that work with 
pointers to memory, and you can't use files (/dev/mem, /proc/self/mem, 
etc), you can't work with backend memory directly.

--
Craig Ringer


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Specification for Trusted PLs?
Next
From: Jan Wieck
Date:
Subject: Re: Specification for Trusted PLs?