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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
