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

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

(1) Is it impossible for an interpreter to switch between trusted and untrusted modes? This is probably a reasonable restriction, but worth calling out loudly in the docs. (2) For the APIs returning an int, it wasn't clear what that int would be, other than NULL => interpreter is trusted. I'm

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 _

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

I have been working on a design doc for restricted execution of Python as part of my dissertation for getting Python into Firefox to replace JavaScript on the web. Since this is dealing with security and messing that up can be costly, I am sending it to the list for any possible feedback. I have