On 5/23/2010 11:19 PM, Andrew Dunstan wrote:
Jan Wieck wrote:
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?
Well, that threat arises from the unsafe actions of the careless
superuser. And we could at least ameliorate it by providing a per role
data stash, at very little cost, as I mentioned. It's not like we don't
know about such threats, and I'm certainly not pretending they don't
exist. The 9.0 PL/Perl docs say:
The %_SHARED variable and other global state within the language is
public data, available to all PL/Perl functions within a session.
Use with care, especially in situations that involve use of multiple
roles or SECURITY DEFINER functions.
But the threats I was referring to arise if the language allows them to,
without any requirement for unsafe actions by another user. Protecting
against those is the essence of trustedness in my mind at least.
I can agree with that.
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
