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.


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:

Reply via email to