Robert Haas wrote:
On Sat, May 22, 2010 at 4:53 PM, C?dric Villemain
cedric.villemain.deb...@gmail.com wrote:
2010/5/21 Jan Wieck janwi...@yahoo.com:
The original idea was that a trusted language does not allow an
unprivileged
user to gain access to any object or data, he does not have
On Thu, May 27, 2010 at 11:09:26PM -0400, Tom Lane wrote:
David Fetter da...@fetter.org writes:
I don't know about a *good* idea, but here's the one I've got.
1. Make a whitelist. This is what needs to work in order for a
language to be a fully functional trusted PL.
Well, I pretty
On fre, 2010-05-28 at 13:03 +0100, Sam Mason wrote:
That's not normally a problem. The conventional way would be to place
the interpreter in its own sandbox, similar to how Chrome has each tab
running in its own process. These processes are protected in a way
so that the code running inside
Sam Mason wrote:
On Thu, May 27, 2010 at 11:09:26PM -0400, Tom Lane wrote:
David Fetter da...@fetter.org writes:
I don't know about a *good* idea, but here's the one I've got.
1. Make a whitelist. This is what needs to work in order for a
language to be a fully functional
Tom Lane wrote:
Joshua Tolley eggyk...@gmail.com writes:
Agreed. As long as a trusted language can do things outside the
database only by going through a database and calling some function to
which the user has rights, in an untrusted language, that seems decent
to me. A user with
On Thu, May 27, 2010 at 11:23:44AM -0400, Bruce Momjian wrote:
Tom Lane wrote:
Joshua Tolley eggyk...@gmail.com writes:
Agreed. As long as a trusted language can do things outside the
database only by going through a database and calling some
function to which the user has rights, in
On Fri, May 28, 2010 at 01:03:15AM +0300, Peter Eisentraut wrote:
On fre, 2010-05-21 at 14:22 -0400, Robert Haas wrote:
On Fri, May 21, 2010 at 2:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
So... can we get back to coming up with a reasonable
On Thu, May 27, 2010 at 7:10 PM, David Fetter da...@fetter.org wrote:
On Fri, May 28, 2010 at 01:03:15AM +0300, Peter Eisentraut wrote:
On fre, 2010-05-21 at 14:22 -0400, Robert Haas wrote:
On Fri, May 21, 2010 at 2:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com
On Thu, May 27, 2010 at 09:51:30PM -0400, Robert Haas wrote:
On Thu, May 27, 2010 at 7:10 PM, David Fetter da...@fetter.org wrote:
On Fri, May 28, 2010 at 01:03:15AM +0300, Peter Eisentraut wrote:
On fre, 2010-05-21 at 14:22 -0400, Robert Haas wrote:
On Fri, May 21, 2010 at 2:21 PM, Tom
David Fetter da...@fetter.org writes:
I don't know about a *good* idea, but here's the one I've got.
1. Make a whitelist. This is what needs to work in order for a
language to be a fully functional trusted PL.
Well, I pretty much lose interest right here, because this is already
assuming
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
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Well, the best way to define what a trusted language can do is to
define a *whitelist* of what it can do, not a blacklist of what it
can't do. That's the only way to get a complete definition. It's then
up to the implementation step to
Tom Lane wrote:
Robert Haas robertmh...@gmail.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
On 5/23/2010 6:14 PM, Ron Mayer wrote:
Tom Lane wrote:
Robert Haas robertmh...@gmail.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
Jan Wieck wrote:
On 5/23/2010 6:14 PM, Ron Mayer wrote:
Tom Lane wrote:
Robert Haas robertmh...@gmail.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
On 21/05/10 23:55, Josh Berkus wrote:
So, here's a working definition:
1) cannot directly read or write files on the server.
It must also prevent PL-user-level access to file descriptors already
open by the backend. That's implicitly covered in the above, but should
probably be explicit.
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 robertmh...@gmail.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)
On 22/05/10 02:12, Robert Haas wrote:
On Fri, May 21, 2010 at 1:58 PM, David Fetterda...@fetter.org wrote:
On Fri, May 21, 2010 at 01:45:45PM -0400, Stephen Frost wrote:
* David Fetter (da...@fetter.org) wrote:
That is *precisely* the business we need to be in, at least for the
languages we
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,
On Fri, May 21, 2010 at 7:25 PM, Magnus Hagander mag...@hagander.net wrote:
On Fri, May 21, 2010 at 12:22 PM, David Fetter da...@fetter.org wrote:
On Fri, May 21, 2010 at 11:57:33AM -0400, Magnus Hagander wrote:
On Fri, May 21, 2010 at 11:55 AM, Josh Berkus j...@agliodbs.com wrote:
So, here's
2010/5/21 Jan Wieck janwi...@yahoo.com:
The original idea was that a trusted language does not allow an unprivileged
user to gain access to any object or data, he does not have access to
without that language.
This does not include data transformation functionality, like string
processing or
On Sat, May 22, 2010 at 4:53 PM, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
2010/5/21 Jan Wieck janwi...@yahoo.com:
The original idea was that a trusted language does not allow an unprivileged
user to gain access to any object or data, he does not have access to
without that
Folks,
I feel dumb.
I have been looking for a document which specifies what trusted and
untrusted PLs must do and forbid, so far without result.
Where do we document this, and if we don't where *should* we document
this?
Cheers,
David.
--
David Fetter da...@fetter.org http://fetter.org/
* David Fetter (da...@fetter.org) wrote:
I have been looking for a document which specifies what trusted and
untrusted PLs must do and forbid, so far without result.
I think you might have been missing the tree for the forest in this
case.. :) I'm sure you've seen this, but perhaps you weren't
That's about it- a language is TRUSTED if there's no way for a user to
be able to write a function which will give them access to things
they're not supposed to have. Practically, this includes things like
any kind of direct I/O (files, network, etc).
The fact that plpythonu used to be
Peter Geoghegan peter.geoghega...@gmail.com writes:
That's about it- a language is TRUSTED if there's no way for a user to
be able to write a function which will give them access to things
they're not supposed to have. Practically, this includes things like
any kind of direct I/O (files,
So, here's a working definition:
1) cannot directly read or write files on the server.
2) cannot bind network ports
3) uses only the SPI interface to interact with postgresql tables etc.
4) does any logging only using elog to the postgres log
Questions:
a) it seems like there should be some
On Fri, May 21, 2010 at 11:55 AM, Josh Berkus j...@agliodbs.com wrote:
So, here's a working definition:
1) cannot directly read or write files on the server.
2) cannot bind network ports
To make that more covering, don't yu really need something like
cannot communicate with outside processes?
On 05/21/2010 11:57 AM, Magnus Hagander wrote:
On Fri, May 21, 2010 at 11:55 AM, Josh Berkusj...@agliodbs.com wrote:
So, here's a working definition:
1) cannot directly read or write files on the server.
2) cannot bind network ports
To make that more covering, don't yu really need something
On Fri, May 21, 2010 at 11:57:33AM -0400, Magnus Hagander wrote:
On Fri, May 21, 2010 at 11:55 AM, Josh Berkus j...@agliodbs.com wrote:
So, here's a working definition:
1) cannot directly read or write files on the server.
2) cannot bind network ports
To make that more covering, don't
* David Fetter (da...@fetter.org) wrote:
These need to be testable conditions, and new tests need to get added
any time we find that we've missed something. Making this concept
fuzzier is exactly the wrong direction to go.
I'm really not sure that we want to be in the business of writing a
On Fri, May 21, 2010 at 12:22 PM, David Fetter da...@fetter.org wrote:
On Fri, May 21, 2010 at 11:57:33AM -0400, Magnus Hagander wrote:
On Fri, May 21, 2010 at 11:55 AM, Josh Berkus j...@agliodbs.com wrote:
So, here's a working definition:
1) cannot directly read or write files on the
On Fri, May 21, 2010 at 12:26:24PM -0400, Stephen Frost wrote:
* David Fetter (da...@fetter.org) wrote:
These need to be testable conditions, and new tests need to get
added any time we find that we've missed something. Making this
concept fuzzier is exactly the wrong direction to go.
* David Fetter (da...@fetter.org) wrote:
That is *precisely* the business we need to be in, at least for the
languages we ship, and it would behoove us to test languages we don't
ship so we can warn people when they don't pass.
k, let's start with something simpler first tho- I'm sure we can
On Fri, May 21, 2010 at 01:45:45PM -0400, Stephen Frost wrote:
* David Fetter (da...@fetter.org) wrote:
That is *precisely* the business we need to be in, at least for the
languages we ship, and it would behoove us to test languages we don't
ship so we can warn people when they don't pass.
On May 21, 2010, at 18:26 , Stephen Frost wrote:
* David Fetter (da...@fetter.org) wrote:
These need to be testable conditions, and new tests need to get added
any time we find that we've missed something. Making this concept
fuzzier is exactly the wrong direction to go.
I'm really not
* David Fetter (da...@fetter.org) wrote:
On Fri, May 21, 2010 at 01:45:45PM -0400, Stephen Frost wrote:
k, let's start with something simpler first tho- I'm sure we can pull in
the glibc regression tests and run them too. You know, just in case
there's a bug there, somewhere.
That's
David Fetter da...@fetter.org writes:
On Fri, May 21, 2010 at 12:26:24PM -0400, Stephen Frost wrote:
I'm really not sure that we want to be in the business of writing a
ton of regression tests to see if languages which claim to be
trusted really are..
That is *precisely* the business we need
On Fri, May 21, 2010 at 1:58 PM, David Fetter da...@fetter.org wrote:
On Fri, May 21, 2010 at 01:45:45PM -0400, Stephen Frost wrote:
* David Fetter (da...@fetter.org) wrote:
That is *precisely* the business we need to be in, at least for the
languages we ship, and it would behoove us to test
Robert Haas robertmh...@gmail.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)
(2) no access to process memory, other than variables defined within the
PL.
What else?
regards,
On Fri, May 21, 2010 at 2:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.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)
(2) no access to process memory, other than variables
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Well, the best way to define what a trusted language can do is to
define a *whitelist* of what it can do, not a blacklist of what it
can't do. That's the only way to get a complete definition. It's then
up to the implementation step to
* Robert Haas (robertmh...@gmail.com) wrote:
So... can we get back to coming up with a reasonable
definition, and
Guess I'm wondering if we could steal such a definition from one of the
languages we allow as trusted already.. Just a thought. I certainly
think we should make sure that we
Greg Sabino Mullane g...@turnstep.com writes:
Well, the best way to define what a trusted language can do is to
define a *whitelist* of what it can do, not a blacklist of what it
can't do.
No, that's exactly backwards. We can't define all the things a language
can do, but we can certainly
Robert Haas robertmh...@gmail.com writes:
On Fri, May 21, 2010 at 2:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
(1) no access to system calls (including file and network I/O)
(2) no access to process memory, other than variables defined within the
PL.
What else?
Doesn't subvert the general
On Fri, May 21, 2010 at 03:15:27PM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, May 21, 2010 at 2:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
(1) no access to system calls (including file and network I/O)
(2) no access to process memory, other than variables
On Fri, May 21, 2010 at 12:36:50PM -0700, David Fetter wrote:
On Fri, May 21, 2010 at 03:15:27PM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, May 21, 2010 at 2:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
(1) no access to system calls (including file and network
On Fri, May 21, 2010 at 1:36 PM, David Fetter da...@fetter.org wrote:
On Fri, May 21, 2010 at 03:15:27PM -0400, Tom Lane wrote:
As long as you can't do database access except via SPI, that should
be covered. So I guess the next item on the list is no, or at least
restricted, access to
Joshua Tolley eggyk...@gmail.com writes:
Agreed. As long as a trusted language can do things outside the
database only by going through a database and calling some function to
which the user has rights, in an untrusted language, that seems decent
to me. A user with permissions to
Howdy,
On Fri, May 21, 2010 at 11:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.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)
(2) no access to process memory, other than
On Fri, May 21, 2010 at 2:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Joshua Tolley eggyk...@gmail.com writes:
Agreed. As long as a trusted language can do things outside the
database only by going through a database and calling some function to
which the user has rights, in an untrusted
The original idea was that a trusted language does not allow an
unprivileged user to gain access to any object or data, he does not have
access to without that language.
This does not include data transformation functionality, like string
processing or the like. As long as the user had
52 matches
Mail list logo
