Re: [Python-Dev] doc for new restricted execution design for Python

On 7/7/06, Greg Ewing <[EMAIL PROTECTED]> wrote: Nick Coghlan wrote:> What would the signature of the file constructor be in that case?If it's possible to call it at all, I think it wouldhave to take a file descriptor, or whatever theplatform's OS-level representation of an open file is.The other p

Re: [Python-Dev] doc for new restricted execution design for Python

Nick Coghlan wrote: > What would the signature of the file constructor be in that case? If it's possible to call it at all, I think it would have to take a file descriptor, or whatever the platform's OS-level representation of an open file is. The other possibility is to just raise an exception

Re: [Python-Dev] doc for new restricted execution design for Python

On 7/7/06, Greg Ewing <[EMAIL PROTECTED]> wrote: Another thing I perhaps should point out is thatI'm proposing the separation of open() and file()for *all* code, not just restricted code. So it'snot a matter of "crippling" file() specially forrestricted code. Well, that's fine with me since I use o

Re: [Python-Dev] doc for new restricted execution design for Python

On 7/7/06, Greg Ewing <[EMAIL PROTECTED]> wrote: Brett Cannon wrote:> On 7/5/06, *Greg Ewing* <[EMAIL PROTECTED]> And I would change file() so that it didn't open> files. Then it would be harmless for code to have > access to the file class.> Right, that is essentially what I proposed i

Re: [Python-Dev] doc for new restricted execution design for Python

Greg Ewing wrote: > Another thing I perhaps should point out is that > I'm proposing the separation of open() and file() > for *all* code, not just restricted code. So it's > not a matter of "crippling" file() specially for > restricted code. What would the signature of the file constructor be in

Re: [Python-Dev] doc for new restricted execution design for Python

Another thing I perhaps should point out is that I'm proposing the separation of open() and file() for *all* code, not just restricted code. So it's not a matter of "crippling" file() specially for restricted code. -- Greg ___ Python-Dev mailing list Pyt

Re: [Python-Dev] doc for new restricted execution design for Python

Brett Cannon wrote: > On 7/5/06, *Greg Ewing* <[EMAIL PROTECTED] > And I would change file() so that it didn't open > files. Then it would be harmless for code to have > access to the file class. > Right, that is essentially what I proposed initially with the whole > crippling idea.

Re: [Python-Dev] doc for new restricted execution design for Python

On 7/5/06, Greg Ewing <[EMAIL PROTECTED]> wrote: Brett Cannon wrote:> Armin in an email said that he thought it was> a losing battle to try to hide 'file' from an interpreter.And I would change file() so that it didn't openfiles. Then it would be harmless for code to have access to the file class.R

Re: [Python-Dev] doc for new restricted execution design for Python

On 7/5/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote: On Wed, 5 Jul 2006, Brett Cannon wrote:> On 7/4/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:> > In response to Guido's comment about confusing the words "trusted" and > > "untrusted", how about "empowered" and "restricted"?>> Maybe.  I am really start

Re: [Python-Dev] doc for new restricted execution design for Python

On 7/6/06, Michael Chermside <[EMAIL PROTECTED]> wrote: I wrote:> I would still rather not spread FUD.Brett Cannon responds:> I don't consider it FUD.  Armin in an email said that he thought it> was a losing battle to try to hide 'file' from an interpreter.  That > is what I am worried about, perio

Re: [Python-Dev] doc for new restricted execution design for Python

I wrote: > I would still rather not spread FUD. Brett Cannon responds: > I don't consider it FUD. Armin in an email said that he thought it > was a losing battle to try to hide 'file' from an interpreter. That > is what I am worried about, period. Everythign else can be > protected through reso

Re: [Python-Dev] doc for new restricted execution design for Python

On Wed, 5 Jul 2006, Brett Cannon wrote: > On 7/4/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote: > > In response to Guido's comment about confusing the words "trusted" and > > "untrusted", how about "empowered" and "restricted"? > > Maybe. I am really starting to lean towards trusted and sandboxed. It

Re: [Python-Dev] doc for new restricted execution design for Python

Brett Cannon wrote: > Armin in an email said that he thought it was > a losing battle to try to hide 'file' from an interpreter. And I would change file() so that it didn't open files. Then it would be harmless for code to have access to the file class. -- Greg _

Re: [Python-Dev] doc for new restricted execution design for Python

On 7/5/06, Michael Chermside <[EMAIL PROTECTED]> wrote: Ka-Ping Yee writes:> If you mean getting from a trusted interpreter to an untrusted> interpreter -- then how is a resource going to travel between> interpreters?Brett Cannon responds:> Beats me, but I am always scared of Armin and Samuele.  =)

Re: [Python-Dev] doc for new restricted execution design for Python

Ka-Ping Yee writes: > If you mean getting from a trusted interpreter to an untrusted > interpreter -- then how is a resource going to travel between > interpreters? Brett Cannon responds: > Beats me, but I am always scared of Armin and Samuele. =) Okay, those two scare me also, but I would still

Re: [Python-Dev] doc for new restricted execution design for Python

On 7/4/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote: Hi Brett,Here are some comments on the description of the restricted executionmodel that you posted.> When referring to the state of an interpreter, it is either "trusted" or> "untrusted".  A trusted interpreter has no restrictions imposed upon any

Re: [Python-Dev] doc for new restricted execution design for Python

Ka-Ping Yee wrote: >Hi Brett, > >Here are some comments on the description of the restricted execution >model that you posted. > > [snip...] > >>Filesystem >>=== >> >>The most obvious facet of a filesystem to protect is reading from it. >>One does not want what is stored in ``/etc/

Re: [Python-Dev] doc for new restricted execution design for Python

Hi Brett, Here are some comments on the description of the restricted execution model that you posted. > When referring to the state of an interpreter, it is either "trusted" or > "untrusted". A trusted interpreter has no restrictions imposed upon any > resource. An untrusted interpreter has at

Re: [Python-Dev] doc for new restricted execution design for Python

Brett Cannon wrote: > > I don't know how JavaScript is doing it yet. The critical thing for me > for this month was trying to come up with a security model. > > And if you don't think it is going to scale, how do you think it should > be done? if I remember correctly, the boundary/granularity

Re: [Python-Dev] doc for new restricted execution design for Python

Mark Hammond wrote: > that helps "mozilla the platform" more than it helps "firebox the browser" ^^^ Firebox - the sandfoxed web browser! -- Greg ___ Python-Dev mailing list Python-Dev@python

Re: [Python-Dev] doc for new restricted execution design for Python

On 6/28/06, Mark Hammond <[EMAIL PROTECTED]> wrote: Bob writes:> I don't know how _javascript_ is doing it yet.  The critical thing> for me for this month was trying to come up with a security model.I don't fully understand how JS does it either, certainly not in any detail. I know that it uses the

Re: [Python-Dev] doc for new restricted execution design for Python

I wrote: > Bob writes: Ack - sorry about that - the HTML mail confused me :) It was Brett, of course. Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailm

Re: [Python-Dev] doc for new restricted execution design for Python

Bob writes: > I don't know how JavaScript is doing it yet. The critical thing > for me for this month was trying to come up with a security model. I don't fully understand how JS does it either, certainly not in any detail. I know that it uses the concept of a "principal" (the IDL file can be se

Re: [Python-Dev] doc for new restricted execution design for Python

Jim Jewett wrote: > IMHO, I would prefer that it limit disk consumption; a deleted or > overwritten file would not count against the process, but even a > temporary spike would need to be less than the cap. The problem is that there's no easy way to reliably measure disk consumption by a particul

Re: [Python-Dev] doc for new restricted execution design for Python

On 6/28/06, Trent Mick <[EMAIL PROTECTED]> wrote: Brett Cannon wrote:> > > The idea is that there be a separate Python interpreter per web> > > browser page instance.>> > I think there may be scaling issues there. _javascript_ isn't doing that > > is it, do you know? As well, that doesn't s

Re: [Python-Dev] doc for new restricted execution design for Python

Brett Cannon wrote: > > > The idea is that there be a separate Python interpreter per web > > > browser page instance. > > > I think there may be scaling issues there. JavaScript isn't doing that > > is it, do you know? As well, that doesn't seem like it would translate > > well to sha

Re: [Python-Dev] doc for new restricted execution design for Python

On 6/28/06, Bill Janssen <[EMAIL PROTECTED]> wrote: > Yep, it would be.  Then again, Mark Hammond has already done a bunch of work> for pyXPCOM, so getting Python compiled right into Firefox itself shouldn't> be too bad.Of course, that's the road Sun first went down with Java, and that turned out n

Re: [Python-Dev] doc for new restricted execution design for Python

Guido van Rossum wrote: > On 6/28/06, Brett Cannon <[EMAIL PROTECTED]> wrote: >> On 6/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: >>> - File size should be rounded up to some block size (512 if you don't >>> have filesystem specific information) before adding to the total. >> Why? > > Becau

Re: [Python-Dev] doc for new restricted execution design for Python

> Yep, it would be. Then again, Mark Hammond has already done a bunch of work > for pyXPCOM, so getting Python compiled right into Firefox itself shouldn't > be too bad. Of course, that's the road Sun first went down with Java, and that turned out not-so-well for them. I think the plug-in approa

Re: [Python-Dev] doc for new restricted execution design for Python

On Jun 28, 2006, at 10:54 AM, Brett Cannon wrote:On 6/28/06, Trent Mick <[EMAIL PROTECTED]> wrote: Brett Cannon wrote: Mark (and me a little bit) has been sketching out creating a "Python forMozilla/Firefox" extension for installing an embedded Python into anexisting Firefox installation on the pyx

Re: [Python-Dev] doc for new restricted execution design for Python

On 6/28/06, Trent Mick <[EMAIL PROTECTED]> wrote: Brett Cannon wrote:> The plan is to allow pure Python code to be embedded into web pages like> _javascript_. ...> ...Then again, Mark Hammond has already done a bunch of work for pyXPCOM, so getting Python compiled right into Firefox itself shouldn'

Re: [Python-Dev] doc for new restricted execution design for Python

On 6/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: On 6/28/06, Brett Cannon <[EMAIL PROTECTED]> wrote:> On 6/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:> > - File size should be rounded up to some block size (512 if you don't > > have filesystem specific information) before adding to th

Re: [Python-Dev] doc for new restricted execution design for Python

On 6/28/06, Jim Jewett <[EMAIL PROTECTED]> wrote: On 6/28/06, Brett Cannon <[EMAIL PROTECTED]> wrote:> On 6/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:> > - File size should be rounded up to some block size (512 if you don't > > have filesystem specific information) before adding to the tota

Re: [Python-Dev] doc for new restricted execution design for Python

On 6/28/06, Brett Cannon <[EMAIL PROTECTED]> wrote: > On 6/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > - File size should be rounded up to some block size (512 if you don't > > have filesystem specific information) before adding to the total. > > Why? Because that's how filesystems work

Re: [Python-Dev] doc for new restricted execution design for Python

Brett Cannon wrote: > The plan is to allow pure Python code to be embedded into web pages like > JavaScript. ... > ...Then again, Mark Hammond has already done a bunch of work for pyXPCOM, so > getting Python compiled right into Firefox itself shouldn't be too bad. > > If this really takes off,

Re: [Python-Dev] doc for new restricted execution design for Python

On 6/28/06, Brett Cannon <[EMAIL PROTECTED]> wrote: > On 6/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > - File size should be rounded up to some block size (512 if you don't > > have filesystem specific information) before adding to the total. > Why? That reflects the amount of disk I

Re: [Python-Dev] doc for new restricted execution design for Python

On 6/27/06, Bill Janssen <[EMAIL PROTECTED]> wrote: > The plan is to allow pure Python code to be embedded into web pages like> _javascript_.  I am not going for the applet approach like Java.Java support is now just a plug-in.  Should be easy to make a Python plug-in system that works the same way

Re: [Python-Dev] doc for new restricted execution design for Python

On 6/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: On 6/28/06, Jim Jewett <[EMAIL PROTECTED]> wrote:> On 6/27/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:> > On 6/27/06, Brett Cannon < [EMAIL PROTECTED]> wrote:> > >> > > > (5)  I think file creation/writing should be capped rather than> > > > b

Re: [Python-Dev] doc for new restricted execution design for Python

On 6/28/06, Jim Jewett <[EMAIL PROTECTED]> wrote: On 6/27/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:> On 6/27/06, Brett Cannon <[EMAIL PROTECTED]> wrote:> >> > > (5)  I think file creation/writing should be capped rather than > > > binary; it is reasonable to say "You can create a single temp file

Re: [Python-Dev] doc for new restricted execution design for Python

On 6/27/06, Neal Norwitz <[EMAIL PROTECTED]> wrote: On 6/27/06, Brett Cannon <[EMAIL PROTECTED]> wrote:>> > (5)  I think file creation/writing should be capped rather than> > binary; it is reasonable to say "You can create a single temp file up > > to 4K" or "You can create files, but not more than

Re: [Python-Dev] doc for new restricted execution design for Python

On 6/28/06, Jim Jewett <[EMAIL PROTECTED]> wrote: > On 6/27/06, Neal Norwitz <[EMAIL PROTECTED]> wrote: > > On 6/27/06, Brett Cannon <[EMAIL PROTECTED]> wrote: > > > > > > > (5) I think file creation/writing should be capped rather than > > > > binary; it is reasonable to say "You can create a sin

Re: [Python-Dev] doc for new restricted execution design for Python

On 6/27/06, Neal Norwitz <[EMAIL PROTECTED]> wrote: > On 6/27/06, Brett Cannon <[EMAIL PROTECTED]> wrote: > > > > > (5) I think file creation/writing should be capped rather than > > > binary; it is reasonable to say "You can create a single temp file up > > > to 4K" or "You can create files, but

Re: [Python-Dev] doc for new restricted execution design for Python

On 6/27/06, Brett Cannon <[EMAIL PROTECTED]> wrote: > > > (5) I think file creation/writing should be capped rather than > > binary; it is reasonable to say "You can create a single temp file up > > to 4K" or "You can create files, but not more than 20Meg total". > > That has been suggested before

Re: [Python-Dev] doc for new restricted execution design for Python

> The plan is to allow pure Python code to be embedded into web pages like > JavaScript. I am not going for the applet approach like Java. Java support is now just a plug-in. Should be easy to make a Python plug-in system that works the same way. If only we had a GUI... :-) Bill __

Re: [Python-Dev] doc for new restricted execution design for Python

On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote: On 6/27/06, Brett Cannon <[EMAIL PROTECTED]> wrote:> On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote:>> > On 6/27/06, Brett Cannon < [EMAIL PROTECTED]> wrote:> Shouldn't be as long as you put the call right after variable declarations> and you don'

Re: [Python-Dev] doc for new restricted execution design for Python

On 6/27/06, Brett Cannon <[EMAIL PROTECTED]> wrote: > On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote: > > > On 6/27/06, Brett Cannon <[EMAIL PROTECTED]> wrote: > Shouldn't be as long as you put the call right after variable declarations > and you don't do an PyObject creation at variable declara

Re: [Python-Dev] doc for new restricted execution design for Python

On 6/27/06, Scott David Daniels <[EMAIL PROTECTED]> wrote: Brett Cannon wrote:> On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote:>>  ...>> Caps and current usage should also be available (though read-only) >> from python; it is quite sensible to spill some cache when getting too>> close to your mem

Re: [Python-Dev] doc for new restricted execution design for Python

Brett Cannon wrote: > On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote: >> ... >> Caps and current usage should also be available (though read-only) >> from python; it is quite sensible to spill some cache when getting too >> close to your memory limit. > > Yeah, being able to read your restricti

Re: [Python-Dev] doc for new restricted execution design for Python

On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote: On 6/27/06, Brett Cannon <[EMAIL PROTECTED]> wrote:> My worry with this is that by providing checking functions that just return> true or false that people will rely on those too much and have logic errors > in their check and let security holes dev

Re: [Python-Dev] doc for new restricted execution design for Python

On 6/27/06, Brett Cannon <[EMAIL PROTECTED]> wrote: > My worry with this is that by providing checking functions that just return > true or false that people will rely on those too much and have logic errors > in their check and let security holes develop. That is why the checking > functions as t

Re: [Python-Dev] doc for new restricted execution design for Python

On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote: On 6/27/06, Brett Cannon <[EMAIL PROTECTED]> wrote:> On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote:> > (2)  For the APIs returning an int, it wasn't clear what that int > > would be, other than NULL => interpreter is trusted.> Doesn't matter.  I

Re: [Python-Dev] doc for new restricted execution design for Python

On 6/27/06, Brett Cannon <[EMAIL PROTECTED]> wrote: > On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote: > > (2) For the APIs returning an int, it wasn't clear what that int > > would be, other than NULL => interpreter is trusted. > Doesn't matter. I should probably change it to a say "a false v

Re: [Python-Dev] doc for new restricted execution design for Python

On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote: (1)  Is it impossible for an interpreter to switch between trusted anduntrusted modes?  This is probably a reasonable restriction, but worthcalling out loudly in the docs.Yes, you should not change the state once the interpreter is used for executio

Re: [Python-Dev] doc for new restricted execution design for Python

On 6/26/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote: Hi, Brett.> I have been working on a design doc for restricted execution of PythonI'm excited to see that you're working on this.Yeah, I just hope I have a design that works.  =) > as part of my dissertation for getting Python into Firefox to repl

Re: [Python-Dev] doc for new restricted execution design for Python

Hi, Brett. > I have been working on a design doc for restricted execution of Python I'm excited to see that you're working on this. > as part of my dissertation for getting Python into Firefox to replace > JavaScript on the web. Wow. What's your game plan? Do you have a story for convincing t

Re: [Python-Dev] doc for new restricted execution design for Python

On Jun 25, 2006, at 1:08 PM, Brett Cannon wrote:On 6/24/06, Bob Ippolito <[EMAIL PROTECTED]> wrote: On Jun 24, 2006, at 2:46 AM, Nick Coghlan wrote:> Brett Cannon wrote:>> Yep.  That API will be used directly in the changes to pymalloc and>> PyMem_*() macros (or at least the basic idea).  It is not

Re: [Python-Dev] doc for new restricted execution design for Python

On 6/24/06, Bob Ippolito <[EMAIL PROTECTED]> wrote: On Jun 24, 2006, at 2:46 AM, Nick Coghlan wrote:> Brett Cannon wrote:>> Yep.  That API will be used directly in the changes to pymalloc and>> PyMem_*() macros (or at least the basic idea).  It is not *only* for >> extension modules but for the cor

Re: [Python-Dev] doc for new restricted execution design for Python

On 6/24/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: Brett Cannon wrote:> Yep.  That API will be used directly in the changes to pymalloc and> PyMem_*() macros (or at least the basic idea).  It is not *only* for> extension modules but for the core as well. >> Existing extension modules and exist

Re: [Python-Dev] doc for new restricted execution design for Python

On Jun 24, 2006, at 2:46 AM, Nick Coghlan wrote: > Brett Cannon wrote: >> Yep. That API will be used directly in the changes to pymalloc and >> PyMem_*() macros (or at least the basic idea). It is not *only* for >> extension modules but for the core as well. >> >> Existing extension modules

Re: [Python-Dev] doc for new restricted execution design for Python

Brett Cannon wrote: > Yep. That API will be used directly in the changes to pymalloc and > PyMem_*() macros (or at least the basic idea). It is not *only* for > extension modules but for the core as well. > > Existing extension modules and existing C code in the Python interpreter > ha

Re: [Python-Dev] doc for new restricted execution design for Python

On 6/22/06, Gerhard Häring <[EMAIL PROTECTED]> wrote: Brett Cannon wrote:> On 6/22/06, *Gerhard Häring* <[EMAIL PROTECTED] [EMAIL PROTECTED]>> wrote:>> Brett Cannon wrote: >  > I have been working on a design doc for restricted execution of> Python>  > [...]>> All the rest of th

Re: [Python-Dev] doc for new restricted execution design for Python

Brett Cannon wrote: > On 6/22/06, *Gerhard Häring* <[EMAIL PROTECTED] > > wrote: > > Brett Cannon wrote: > > I have been working on a design doc for restricted execution of > Python > > [...] > > All the rest of the API made sense to me, but I coul

Re: [Python-Dev] doc for new restricted execution design for Python

On 6/22/06, Gerhard Häring <[EMAIL PROTECTED]> wrote: Brett Cannon wrote:> I have been working on a design doc for restricted execution of Python> [...]All the rest of the API made sense to me, but I couldn't understand whyPyXXX_MemoryFree is needed. How could memory usage possibly fall below 0?It

Re: [Python-Dev] doc for new restricted execution design for Python

Brett Cannon wrote: > I have been working on a design doc for restricted execution of Python > [...] All the rest of the API made sense to me, but I couldn't understand why PyXXX_MemoryFree is needed. How could memory usage possibly fall below 0? -- Gerhard _