Brett Cannon wrote:
Using a factory method callback, one could store the PyCodeObject in a C
proxy object that just acts as a complete delegate, forwarding all method
calls to the internally stored PyCodeObject. That would work.
For this initial implementation, though, I am not going to
On 7/10/06, Talin [EMAIL PROTECTED] wrote:
Brett Cannon wrote: Using a factory method callback, one could store the PyCodeObject in a C proxy object that just acts as a complete delegate, forwarding all method calls to the internally stored PyCodeObject.That would work.
For this initial
On 7/11/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 10:56 AM 7/11/2006 -0700, Brett Cannon wrote:On 7/10/06, Talin mailto:[EMAIL PROTECTED][EMAIL PROTECTED] wrote:(Although, I've often wished for Python to have a variant of __call__
that could be used to override individual methods,
At 11:35 AM 7/11/2006 -0700, Brett Cannon wrote:
On 7/11/06, Phillip J. Eby
mailto:[EMAIL PROTECTED][EMAIL PROTECTED] wrote:
At 10:56 AM 7/11/2006 -0700, Brett Cannon wrote:
On 7/10/06, Talin
mailto:[EMAIL PROTECTED]mailto:[EMAIL PROTECTED][EMAIL PROTECTED]
wrote:
(Although, I've often
On 7/8/06, Talin [EMAIL PROTECTED] wrote:
Brett Cannon wrote: On 7/7/06, Guido van Rossum [EMAIL PROTECTED] wrote: On 7/8/06, Ka-Ping Yee [EMAIL PROTECTED]
wrote: I'd like the answer to be yes.It sounded for a while like this was not part of Brett's plan, though.Now i'm not so sure.It sounds
On 7/7/06, Talin [EMAIL PROTECTED] wrote:
Brett Cannon wrote: On 7/7/06, Guido van Rossum [EMAIL PROTECTED] wrote: On 7/7/06, Brett Cannon [EMAIL PROTECTED]
wrote: I guess I am just not seeing where your approach is better than preventing the constructor in 'file' and having open() return the
On 7/7/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 7/8/06, Ka-Ping Yee [EMAIL PROTECTED] wrote: The situation you're describing here is a classic case of one component keeping a closely held authority while using it to
provide some limited capability to some other component.This comes up
Brett Cannon wrote:
On 7/7/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 7/8/06, Ka-Ping Yee [EMAIL PROTECTED] wrote:
I'd like the answer to be yes. It sounded for a while like this
was not part of Brett's plan, though. Now i'm not so sure. It
sounds like you're also interested in
Brett Cannon wrote:
On 7/5/06, Talin [EMAIL PROTECTED] wrote:
Transitioning from the checked to the unchecked state could only be done
via C code. So the 'file' wrapper, for example, would switch over to the
unchecked interpreter before calling the actual methods of 'file'. That
C wrapper
On 7/6/06, Talin [EMAIL PROTECTED] wrote:
Brett Cannon wrote: On 7/5/06, Talin [EMAIL PROTECTED] wrote: Transitioning from the checked to the unchecked state could only be done via C code. So the 'file' wrapper, for example, would switch over to the
unchecked interpreter before calling the actual
Brett Cannon wrote:
On 7/6/06, Talin [EMAIL PROTECTED] wrote:
And if we can call it for every operation, then we don't have to spend
time hunting down all of the possible loopholes and ways in which 'file'
or other restricted objects might be accessed.
Not true. You have to set this object
On 7/7/06, Talin [EMAIL PROTECTED] wrote:
Brett Cannon wrote: On 7/6/06, Talin [EMAIL PROTECTED] wrote: And if we can call it for every operation, then we don't have to spend time hunting down all of the possible loopholes and ways in which 'file'
or other restricted objects might be accessed.
On 7/7/06, Brett Cannon [EMAIL PROTECTED] wrote:
I guess I am just not seeing where your approach is better than preventing
the constructor in 'file' and having open() return the 'file' object or
proxy object. With your approach 'file' would be flagged, but with the
other you just put the
On 7/7/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 7/7/06, Brett Cannon [EMAIL PROTECTED] wrote: I guess I am just not seeing where your approach is better than preventing the constructor in 'file' and having open() return the 'file' object or
proxy object.With your approach 'file' would be
Brett Cannon wrote:
Good point. C code could circumvent the bit check by doing all of the
work behind the scenes without pushing the object on the stack. But if
the check is in the C code for the object itself it is much harder to
get around.
C code can circumvent the bit check by
On 7/7/06, Nick Coghlan [EMAIL PROTECTED] wrote:
Brett Cannon wrote:Good point.C code could circumvent the bit check by doing all of the work behind the scenes without pushing the object on the stack.But if the check is in the C code for the object itself it is much harder to
get around.C code
Brett Cannon wrote:
On 7/7/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 7/7/06, Brett Cannon [EMAIL PROTECTED] wrote:
I guess I am just not seeing where your approach is better than
preventing
the constructor in 'file' and having open() return the 'file' object or
proxy object.
On Fri, 7 Jul 2006, Talin wrote:
While I was typing this, I did realize a drawback to poisoned objects,
which I will illustrate by the following example:
Suppose we want to grant to the sandboxed program permission to read and
write cofiguration properties. We don't want to give them
On 7/8/06, Ka-Ping Yee [EMAIL PROTECTED] wrote:
The situation you're describing here is a classic case of one
component keeping a closely held authority while using it to
provide some limited capability to some other component. This
comes up quite often when you're trying to write secure
On 7/5/06, Talin [EMAIL PROTECTED] wrote:
Brett Cannon wrote: On 7/5/06, Michael Chermside [EMAIL PROTECTED] wrote: If you were using capabilities, you would need to ensure that restricted interpreters could only get the file object that they
were given. But then _all_ of these fancy versions of
In response to Ka-Ping's comments on the subject of Resource Hiding
vs Resource Crippling, Brett says:
It seems that your criticisms are aimed at resource crippling
being a plug holes as needed but if you foul up you are screwed
with resource hiding being more fix the fundamental issues and
Michael Chermside wrote:
That leaves the other problem: auxiliary means of accessing
objects. There are things like gc.get_objects(). In the special
case of file, which is a type that's also dangerous, there are
tricks like object().__class__.__subclasses__().
My approach to that would be to
Brett Cannon wrote:
On 7/5/06, Michael Chermside [EMAIL PROTECTED] wrote:
If you were using capabilities, you would need to ensure that
restricted interpreters could only get the file object that they
were given. But then _all_ of these fancy versions of the
restrictions would be immediately
23 matches
Mail list logo
