Обсуждение: Interpretation of TRUSTED

Поиск
Список
Период
Сортировка

Interpretation of TRUSTED

От
Thomas Hallgren
Дата:
Hi,
A TRUSTED language specifies that ordinary users can use the language. 
It also implies that access to the file system should be prevented. In 
essence, ordinary users can never access the filesystem.

Is it OK to design a trusted language so that it allows access to the 
filesystem provided that the session user is a super-user?

Regards,
Thomas Hallgren




Re: Interpretation of TRUSTED

От
David Fetter
Дата:
On Tue, Feb 08, 2005 at 11:12:07PM +0100, Thomas Hallgren wrote:
> Hi,
> A TRUSTED language specifies that ordinary users can use the
> language.  It also implies that access to the file system should be
> prevented. In essence, ordinary users can never access the
> filesystem.
> 
> Is it OK to design a trusted language so that it allows access to
> the filesystem provided that the session user is a super-user?

I believe that that is what UNTRUSTED languages are for.  Only the
super-user may create functions in them, although there is no inherent
restriction on other users' calling those functions.

Cheers,
D
-- 
David Fetter david@fetter.org http://fetter.org/
phone: +1 510 893 6100   mobile: +1 415 235 3778

Remember to vote!


Re: Interpretation of TRUSTED

От
elein@varlena.com (elein)
Дата:
An untrusted language is so because of what it can do and cannot do.
An untrusted language cannot access the filesystem, for example.

WHO writes and runs untrusted and trusted procedures is a different
thing.  It is the security mechanism meant to restrict writting
and running the functions written in a trusted/untrusted language.

--elein

On Tue, Feb 08, 2005 at 11:12:07PM +0100, Thomas Hallgren wrote:
> Hi,
> A TRUSTED language specifies that ordinary users can use the language. 
> It also implies that access to the file system should be prevented. In 
> essence, ordinary users can never access the filesystem.
> 
> Is it OK to design a trusted language so that it allows access to the 
> filesystem provided that the session user is a super-user?
> 
> Regards,
> Thomas Hallgren
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>    (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
> 


Re: Interpretation of TRUSTED

От
Thomas Hallgren
Дата:
elein wrote:

>An untrusted language is so because of what it can do and cannot do.
>An untrusted language cannot access the filesystem, for example.
>
>WHO writes and runs untrusted and trusted procedures is a different
>thing.  It is the security mechanism meant to restrict writting
>and running the functions written in a trusted/untrusted language.
>  
>
Ok, that makes a lot of sense. I read the documentation: "3.4.1 
Installing Procedural Languages". It is a bit vague on what an untrusted 
language should be prevented from doing. "do not allow access to 
database server internals or the file system" is what it says. How about 
network access? Is there a more canonical definition somewhere that I 
can read ?

Regards,
Thomas Hallgren




Re: Interpretation of TRUSTED

От
Tom Lane
Дата:
David Fetter <david@fetter.org> writes:
> On Tue, Feb 08, 2005 at 11:12:07PM +0100, Thomas Hallgren wrote:
>> Is it OK to design a trusted language so that it allows access to
>> the filesystem provided that the session user is a super-user?

> I believe that that is what UNTRUSTED languages are for.  Only the
> super-user may create functions in them, although there is no inherent
> restriction on other users' calling those functions.

AFAICS, what Thomas proposes would be exactly equivalent to root running
scripts owned by non-root users --- in this case, if session user is
root then functions written by other people would be allowed to do
things they normally shouldn't be able to do.  It strikes me as a great
loophole for Trojan-horse functions.  Not that a sane superuser would
run functions controlled by other people in the first place.
        regards, tom lane


Re: Interpretation of TRUSTED

От
Andrew Dunstan
Дата:

Tom Lane wrote:

>  
>
>>On Tue, Feb 08, 2005 at 11:12:07PM +0100, Thomas Hallgren wrote:
>>    
>>
>>>Is it OK to design a trusted language so that it allows access to
>>>the filesystem provided that the session user is a super-user?
>>>      
>>>
>
>AFAICS, what Thomas proposes would be exactly equivalent to root running
>scripts owned by non-root users --- in this case, if session user is
>root then functions written by other people would be allowed to do
>things they normally shouldn't be able to do.  It strikes me as a great
>loophole for Trojan-horse functions.  Not that a sane superuser would
>run functions controlled by other people in the first place.
>
>
>  
>

Agreed.

It's also not how other PLs work. I don't think this definition should 
be up to the individual language. So my answer to his question above 
would be "No".

cheers

andrew


Re: Interpretation of TRUSTED

От
Jeff Davis
Дата:
On Tue, 2005-02-08 at 14:51 -0800, elein wrote:
> An untrusted language is so because of what it can do and cannot do.
> An untrusted language cannot access the filesystem, for example.
> 

There is a bit of confusion in the terminology. Trusted means that the
language has been deemed "safe", i.e. it cannot do things like access
the filesystem. An untrusted language is not safe, i.e. it can do things
that you would not want an ordinary user to do.

I can see how someone would be easily confused about the terminology,
and I have to think about it each time. Trusted vs. untrusted refers to
the language, not the user of the language.

Regards,Jeff Davis