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
Import Notes
Reference msg id not found: 42093937.6040200@mailblocks.com
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
Show quoted text
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