Re: Specification for Trusted PLs?

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