Thread: Interpretation of TRUSTED
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
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!
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) >
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
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
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
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