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 02:45:35 |
Message-ID: | 4BF9E84F.3010508@Yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 5/23/2010 10:04 PM, Andrew Dunstan wrote:
>
> Jan Wieck wrote:
>> On 5/23/2010 6:14 PM, Ron Mayer wrote:
>>> Tom Lane wrote:
>>>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>>>> So... can we get back to coming up with a reasonable
>>>>> definition,
>>>>
>>>> (1) no access to system calls (including file and network I/O)
>>>
>>> If a PL has file access to it's own sandbox (similar to what
>>> flash seems to do in web browsers), could that be considered
>>> trusted?
>>
>> That is a good question.
>>
>> Currently, the first of all TRUSTED languages, PL/Tcl, would allow the
>> function of a lesser privileged user access the "global" objects of
>> every other database user created within the same session.
>>
>> These are per backend in memory objects, but none the less, an evil
>> function could just scan the per backend Tcl namespace and look for
>> compromising data, and that's not exactly what TRUSTED is all about.
>>
>> In the case of Tcl it is possible to create a separate "safe"
>> interpreter per DB role to fix this. I actually think this would be
>> the right thing to do.
>>
>
> I think that would probably be serious overkill. Maybe a data stash per
> role rather than an interpreter per role would be doable. it would
> certainly be more lightweight.
>
> 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?
Jan
--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2010-05-24 03:16:58 | Re: Specification for Trusted PLs? |
Previous Message | Craig Ringer | 2010-05-24 02:25:57 | Re: Specification for Trusted PLs? |