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
functionswithin a session. Use with care, especially in situations that involve use of multiple roles or SECURITY
DEFINERfunctions.
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.
cheers
andrew