From: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>, Magnus Hagander <magnus(at)hagander(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Specification for Trusted PLs? |
Date: | 2010-05-24 12:17:14 |
Message-ID: | 4BFA6E4A.9010802@Yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-05-24 13:18:40 | Re: ExecutorCheckPerms() hook |
Previous Message | KaiGai Kohei | 2010-05-24 06:52:08 | Re: [v9.1] access control reworks in ALTER TABLE |