On 5/23/2010 10:04 PM, Andrew Dunstan wrote:
Jan Wieck wrote:
On 5/23/2010 6:14 PM, Ron Mayer wrote:
Tom Lane wrote:
Robert Haas <robertmh...@gmail.com> writes:
So... can we get back to coming up with a reasonable
definition,
(1) no access to system calls (including file and network I/O)
If a PL has file access to it's own sandbox (similar to what
flash seems to do in web browsers), could that be considered
trusted?
That is a good question.
Currently, the first of all TRUSTED languages, PL/Tcl, would allow the
function of a lesser privileged user access the "global" objects of
every other database user created within the same session.
These are per backend in memory objects, but none the less, an evil
function could just scan the per backend Tcl namespace and look for
compromising data, and that's not exactly what TRUSTED is all about.
In the case of Tcl it is possible to create a separate "safe"
interpreter per DB role to fix this. I actually think this would be
the right thing to do.
I think that would probably be serious overkill. Maybe a data stash per
role rather than an interpreter per role would be doable. it would
certainly be more lightweight.
ISTM we are in danger of confusing several different things. A user that
doesn't want data to be shared should not stash it in global objects.
But to me, trusting a language is not about making data private, but
about not allowing the user to do things that are dangerous, such as
referencing memory, or the file system, or the operating system, or
network connections, or loading code which might do any of those things.
How is "loading code which might do any of those things" different from
writing a stored procedure, that accesses data, a careless "superuser"
left in a global variable? Remember, the code of a PL function is "open"
source - like in "everyone can select from pg_proc". You really don't
expect anyone to scan for your global variables just because they can
write functions in the same language?
Jan
--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
