Re: Specification for Trusted PLs?

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