Robert Haas wrote:
> On Sat, May 22, 2010 at 4:53 PM, C?dric Villemain
> wrote:
> > 2010/5/21 Jan Wieck :
> >> 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.
>
Sam Mason wrote:
On Thu, May 27, 2010 at 11:09:26PM -0400, Tom Lane wrote:
David Fetter 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.
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 insi
On Thu, May 27, 2010 at 11:09:26PM -0400, Tom Lane wrote:
> David Fetter 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 los
David Fetter 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 that every poten
On Thu, May 27, 2010 at 09:51:30PM -0400, Robert Haas wrote:
> On Thu, May 27, 2010 at 7:10 PM, David Fetter 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 wro
On Thu, May 27, 2010 at 7:10 PM, David Fetter 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 wrote:
>> > > Robert Haas writes:
>> > >> So... can we get back to comi
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 wrote:
> > > Robert Haas writes:
> > >> So... can we get back to coming up with a reasonable
> > >> definition,
> > >
> > > (1) n
On fre, 2010-05-21 at 14:22 -0400, Robert Haas wrote:
> On Fri, May 21, 2010 at 2:21 PM, Tom Lane wrote:
> > Robert Haas 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
On Thu, May 27, 2010 at 11:23:44AM -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > Joshua Tolley 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 untru
Tom Lane wrote:
> Joshua Tolley 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 la
-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
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 allowin
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 22/05/10 02:12, Robert Haas wrote:
On Fri, May 21, 2010 at 1:58 PM, David Fetter 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 woul
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 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 acces
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.
Jan Wieck wrote:
On 5/23/2010 6:14 PM, Ron Mayer wrote:
Tom Lane wrote:
Robert Haas 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
On 5/23/2010 6:14 PM, Ron Mayer wrote:
Tom Lane wrote:
Robert Haas 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 b
Tom Lane wrote:
> Robert Haas 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 considere
On Sat, May 22, 2010 at 4:53 PM, Cédric Villemain
wrote:
> 2010/5/21 Jan Wieck :
>> 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 trans
2010/5/21 Jan Wieck :
> 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
On Fri, May 21, 2010 at 7:25 PM, Magnus Hagander wrote:
> On Fri, May 21, 2010 at 12:22 PM, David Fetter 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 wrote:
>>> > So, here's a working definition:
>>> >
>>> > 1) canno
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 legitim
On Fri, May 21, 2010 at 2:04 PM, Tom Lane wrote:
> Joshua Tolley 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.
Howdy,
On Fri, May 21, 2010 at 11:21 AM, Tom Lane wrote:
> Robert Haas 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
>
Joshua Tolley 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 launch_missiles() would have
On Fri, May 21, 2010 at 1:36 PM, David Fetter 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 functions outside
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 writes:
> > > On Fri, May 21, 2010 at 2:21 PM, Tom Lane wrote:
> > >> (1) no access to system calls (including file and network I/O)
> > >> (2) no access to pr
On Fri, May 21, 2010 at 03:15:27PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Fri, May 21, 2010 at 2:21 PM, Tom Lane 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
Robert Haas writes:
> On Fri, May 21, 2010 at 2:21 PM, Tom Lane 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 PostgreSQL security mechanisms?
"Greg Sabino Mullane" 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 lay out t
* 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 doc
-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 f
On Fri, May 21, 2010 at 2:21 PM, Tom Lane wrote:
> Robert Haas 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.
>
> W
Robert Haas 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, tom lane
--
Sent vi
On Fri, May 21, 2010 at 1:58 PM, David Fetter 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 languag
David Fetter 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 to be in
* 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.
>
> Th
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
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
* 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 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
On Fri, May 21, 2010 at 12:22 PM, David Fetter 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 wrote:
>> > So, here's a working definition:
>> >
>> > 1) cannot directly read or write files on the server.
>> > 2) cannot bin
* 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 11:57:33AM -0400, Magnus Hagander wrote:
> On Fri, May 21, 2010 at 11:55 AM, Josh Berkus 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 real
On 05/21/2010 11:57 AM, Magnus Hagander wrote:
On Fri, May 21, 2010 at 11:55 AM, Josh Berkus 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 comm
On Fri, May 21, 2010 at 11:55 AM, Josh Berkus 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"?
--
Magnu
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 kin
Peter Geoghegan 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, network, etc).
> The fa
> 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 pl
* 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'
52 matches
Mail list logo
