Re: [Python-Dev] new security doc using object-capabilities

[Brett Cannon]

On 7/23/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
At 09:27 PM 7/23/2006 -0700, Brett Cannon wrote:When I say "name checker" I mean the Zope type that allows you to specify alist of names that are allowed for a given object.  This allowing is not
based on identity or code signing or anything like that.  It's just a listof attribute names: i.e. a capability mask over an existing object.When you create a proxy using this name mask, that proxy becomes a
capability that allows access to the given names on the underlying object.OK, then using the term "namechecker" through me off.
>I like the fundemental design difference of object-capabilitiesIt's not a difference at all, let alone a fundamental one.  Zope justhappens to allow other kinds of security checking *in addition to*capabilities, if you want them.  However, most of its more basic
encapsulation features are 100% capability based. Meanwhile, if you want to implement an object-capability system, you will
need something that is basically a mask, to allow one piece of code tocreate capabilities that can be given to another.  What you end up with fordoing that is going to look almost exactly like a Zope proxy plus a Zope
name checker. I hate to harp on this point, but there seems to be a trend that when
people have capabilities on their mind, they tend to look at Zope anddismiss it as not being capability-based, when in fact Zope's approach iscapabilities *plus* other things.Well, Jim said that Zope proxies didn't conform to the strict definition of object-capabilities the last time this all came about: 
http://mail.python.org/pipermail/python-dev/2003-March/033884.html and 
http://mail.python.org/pipermail/python-dev/2003-March/033915.html .  He said they *could* be made to be what object-capabilities is defined as, but they were not currently structured that way.  Those comments are one of the reasons I never considered thinking of Zope proxies as a object-capabilities system.
(Of course, most of those "other things" have to do with closing holes like
__subclasses__, while improving performance by still allowing lots ofcommon objects not to be proxied.)OK, then I need something clarified.  If you read 
http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/TransitionToSecurityProxies , it talks about creating the proxies.  I get they restrict attribute access and wrap all returned objects in proxies themselves (unless they are considered safe).  But to judge whether an attribute should be returned, it checks the security context.  It also mentions how access to the security policy must be available so that proper security checks can be done to either grant or deny access.
So what I want to know is if this security context is this global thing that proxies access every time to check whether something is allowed or not.  Or is it a per-object specification?  And what is the security domain for Zope proxies; objects, interpreter, running Python program, what?
-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Strategy for converting the decimal module to C

[Nick Maclaren]

James Y Knight <[EMAIL PROTECTED]> wrote:
> 
> > To cut a long story short, it is impractical for a language run-time
> > system to call user-defined handlers with any degree of reliability
> > unless the compiled code and run-time interoperate carefully - I have
> > been there and done that many times, but few people still working  
> > have.
> > On architectures with out-of-order execution (and interrupts), you
> > have to assume that an interrupt may occur anywhere, even when the
> > code does not use the relevant facility.  Floating-point overflow
> > in the middle of a list insertion?  That's to be expected.
> 
> While this _is_ a real problem, is it _not_ a general problem as you  
> are describing it. Processors are perfectly capable of generating  
> precise interrupts, and the inability to do so has nothing to do with  
> the out-of-order execution, etc. Almost all interrupts are precise.  

I am sorry, but this is almost totally wrong, though I agree that you
will get that impression upon reading the architecture books unless
you are very deeply into that area.

Let's skip the hardware issues, as they aren't what I am talking about
(though see [*]).  I am referring to the interaction between the
compiled code, deep library functions and run-time interrupt handler.

It is almost universal for some deep library functions and common for
compiled code to leave data structures inconsistent in a short window
that "cannot possibly fail" - indeed, most system interfaces do this
around system calls.  If an interrupt occurs then, the run-time system
will receive control with those data structures in a state where they
must not be accessed.  And it is fairly common for such data structures
to include ones critical to the functioning of the run-time system.

Now, it IS possible to write run-time systems that are safe against
this, and still allow asynchronous interrupts, but I am one of three
people in the world that I know have done it in the past two decades.
There may be as many as six, but I doubt more, and I know of no such
implementation on any Unix or Microsoft system.  It is even possible
to do this for compiled code, but that is where the coordination between
the compiler and run-time system comes in.

> The only interesting one which is not, on x86 processors, is the x87  
> floating point exception, ...

Er, no.  Try a machine-check in a TLB miss handler.  But it is all
pretty irrelevant, as the problem arises with asychronous exceptions
(e.g. timer interrupts, signals from other processes), anyway.

> Also, looking forward, the "simd" floating point instructions (ie mmx/ 
> sse/sse2/sse3) _do_ ...

The critical problems with the x87 floating-point exception were
resolved in the 80386.


[*]  Whether or not it is a fundamental problem, it is very much
a general problem at present, and it will become more so as more CPUs
implement micro-threading.  For why it is tied up with out-of-order
execution etc., consider a system with 100 operations flying, of which
10 are memory accesses, and then consider what happens when you have
combinations of floating-point exceptions, TLB misses, machine-checks
(e.g. ECC problems on memory) and device/timer interrupts.  Once you
add user-defined handlers into that mix, you either start exposing
that mess to the program or have to implement them by stopping the
CPU, unwinding the pipeline, and rerunning in very, very serial mode
until the handler is called.  Look at IA64 


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  [EMAIL PROTECTED]
Tel.:  +44 1223 334761Fax:  +44 1223 334679
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] new security doc using object-capabilities

[Nick Coghlan]

Brett Cannon wrote:
> On 7/23/06, *Armin Rigo* <[EMAIL PROTECTED] > wrote:
> Also, I hate to sound self-centered, but I should point out somewhere
> that PyPy was started by people who no longer wanted to maintain a fork
> of CPython, and preferred to work on building CPython-like variants
> automatically.  Many of the security features you list would be quite
> easier to implement and maintain in PyPy than CPython -- also from a
> security perspective: it is easier to be sure that some protection is
> complete, and remains complete over time, if it is systematically
> generated instead of hand-patched in a dozen places.
> 
> 
> It doesn't sound self-centered.  =)  Problem is that my knowledge base 
> is obviously all in CPython so my startup costs are much lower than if I 
> tried this in PyPy.  Plus there is the point of embedding this into 
> Firefox (possibly) eventually.  Does PyPy support embedding yet at the C 
> level?

Another rationale for basing the work on CPython is that it should be possible 
to implement the resulting security model regardless of the implementation 
language used for the interpreter core (C/Python, Java/Python, C#/Python, 
RPython/Python). If you can figure out how to do it in C, it should be 
feasible to do it in the others.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Document performance requirements?

[Armin Rigo]

Hi Giovanni,

On Sun, Jul 23, 2006 at 03:30:50PM +0200, Giovanni Bajo wrote:
> I'm not sure big-O tells the whole truth. For instance, do we want to allow
> an implementation to use a hash table as underlying type for a list? It
> would match big-O requirements, but would still be slower than a plain array
> because of higher overhead of implementation (higher constant factor).

A big-O difference can make the difference between a program that takes
0.5 seconds or 2 hours to run.  This is more important than a constant
factor difference, which different implementations are bound to exhibit
anyway.

> And if this is allowed, I would like to find in CPython tutorials and
> documentations a simple statement like: "to implement the list and match its
> requirements, CPython choose a simple array as underlying data structure".

Yes, the big-O notes don't have to be too technical: the docs should
tell people to think about Python lists as simple arrays, and the O
requirements follow naturally.


A bientot,

Armin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Python sprint in Arlington July 29/30

[A.M. Kuchling]

The CanDo developers are sprinting for three days starting on this
coming Friday, so there's space available for a Python sprint.  I'll
try to attend at least on Saturday (Sunday may not be possible for
me).  Does anyone want to come and work on Python stuff?  If yes,
please add your name to ,
which also has directions.

Given that Python will still be in a code freeze, we'll have to be
careful about code changes.  I'm probably going to work on
documentation issues.

--amk
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] new security doc using object-capabilities

[Phillip J. Eby]

At 12:50 AM 7/24/2006 -0700, Brett Cannon wrote:
>OK, then I need something clarified.  If you read 
>http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/TransitionToSecurityProxies
> 
>, it talks about creating the proxies.  I get they restrict attribute 
>access and wrap all returned objects in proxies themselves (unless they 
>are considered safe).  But to judge whether an attribute should be 
>returned, it checks the security context.

That depends on the checker.  The proxy implementation delegates all access 
decisions to a "checker" object.  Some checkers check permissions, but a 
NamesChecker just checks a statically-defined list of names.


>   It also mentions how access to the security policy must be available so 
> that proper security checks can be done to either grant or deny access.
>
>So what I want to know is if this security context is this global thing 
>that proxies access every time to check whether something is allowed or not.

Proxies don't do that; checkers do.  The default Checker implementation 
doesn't even look at a security context if a name is declared public (i.e., 
it's a NamesChecker).  Look at the zope.security.checker module for details.

IOW, to make it a pure capabilities system, you would only *delete* code, 
not add any, as far as I can tell.


>   Or is it a per-object specification?

Each proxy can have its own checker, but an individual checker instance can 
be shared between proxies.


>   And what is the security domain for Zope proxies; objects, interpreter, 
> running Python program, what?

There are restricted eval and exec operations to run restricted code.

The primary language limitations imposed are the lack of eval/exec by the 
restricted code, and lack of support for raise and 
try/except.  Implementing these would require additional compiler hacking 
to add code to ensure that e.g. tracebacks get wrapped.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] setup.py and cross-compiling

[Ed Swierk]

I'm cross-compiling Python using uClibc buildroot, which installs target include
files and libraries to a directory like ~/toolchain rather than /usr.  I
couldn't figure out any way to convincing the top-level python/setup.py to look
in ~/toolchain instead of /usr when detecting what modules to build.  

I decided to hack up setup.py so that an optional root directory (passed via an
environment variable) is prepended to all the hardcoded paths like
"/usr/include", "/lib", "/lib64", and so on.

Am I missing an easier solution to this problem?  I'm happy to post my patch to
setup.py if anyone is interested.

--Ed


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 2.4, VS 2005 & Profile Guided Optmization

[Joe Smith]

"Greg Ewing" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Joe Smith wrote:
>
>> Microsoft as a general rule, does not go after people distributing 
>> products
>> that Microsoft has labeled
>> free, even after Microsoft no longer distributes that product.
>
> But if the licence agreement technically forbids
> redistribution, it doesn't seem like a good idea
> to rely on Microsoft turning a blind eye to that.

I agree, although it seems very unlikely Microsoft would
bother as they are busy enough the the pirating of the for-cost software.

I was a little surprised that they did not allow verbatim duplicates of that 
software,
expecially as it has the feel of freeware, or even shareware (the commecial 
versions
have additional features). I would actually not be surprised if somebody 
could
convince Microsoft to allow them to distribute these versions even after 
Microsoft
no longer supports them. That would be the ideal situation.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] new security doc using object-capabilities

[David Hopwood]

Phillip J. Eby wrote:
> At 11:07 PM 7/23/2006 +0100, David Hopwood wrote:
>> Phillip J. Eby wrote:
>> > At 01:00 PM 7/23/2006 -0700, Brett Cannon wrote:
>> >
>> >> I obviously don't want to change the feel of Python, but if I have to
>> >> remove the constructor for code objects to prevent evil bytecode or
>> >> __subclasses__() from object to prevent poking around stuff, then so be
>> >> it.  For this project, security is [trumping] backwards-compatibility when
>> >> the latter is impossible in order to have the former.  I will obviously
>> >> try to minimize it, but something that works at such a basic level of the
>> >> language is just going to require some changes for it to work.
>> >
>> > Zope 3's sandboxing machinery manages to handle securing these things
>> > without any language changes.  So, declaring it "impossible" to manage
>> > without backward compatibility seems inappropriate, or at least
>> > incorrect.
>>
>> ... if Zope's sandboxing is secure. I haven't done a security review
>> of it, but your argument assumes that it is.
> 
> What argument is that?

You said "Zope 3's sandboxing machinery manages to handle securing these
things without any language changes." This assertion assumes that Zope 3's
sandboxing machinery is secure.

> I'm merely suggesting that coming up with a
> completely new way to secure Python without a serious consideration of
> existing practical prior art (with many years' deployment experience on
> the public internet!) seems ill-advised with respect to achieving
> practical goals.
> 
> Brett's securing_python.txt don't refer to or cite Zope in any way,

This is indeed an omission that should be corrected, in order to explain
why this project is not using Zope or following Zope's approach, and what
the differences are. (I've explained some of them below.)

> but rather relies on broad and unsupported assertions about what can or
> can't be done with Python.  I hope he isn't doing the same in his
> thesis, as this is rather like writing about one's new theory of how to
> have a worldwide ball-kicking contest without making any reference as to
> how one's theory compares with the World Cup.
> 
> I'm not saying Zope is better or worse.  I'm simply saying that in a
> business context, a failure to compare and contrast a proposed "build"
> solution to show how it would be better than a well-established
> available "buy" solution would be called something like "lack of due
> diligence".  I think in the academic context it might be called
> something like "failure to cite", but the general idea is the same,
> i.e., not doing your homework.  :)
> 
> In other words, if the solution being proposed is better than what Zope
> does, the appropriate thing in business is to show the reasons why, and
> the appropriate thing in science is to state a hypothesis regarding the
> differences, and then perform an experiment to either prove or disprove it.

I completely agree with this.

>> In any case, Zope's sandboxing is not capability-based.
> 
> You're right: you haven't done a review of it.  :)

I haven't done a detailed security review. However, I wouldn't have commented
on it without knowing what its basic approach is.

From
:

# When an object is passed to untrusted code, it is wrapped in a security
# proxy unless it is already wrapped. Security proxies mediate all accesses
# to the wrapped object. Operations on security proxies return security
# proxies as well. Security proxies passed from untrusted code to trusted
# code remain wrapped, so untrusted code can't trick trusted code into
# performing operations that the untrusted code could not perform.

Restricting the actions of "trusted" code when called by "untrusted" code
is precisely what a capability system does *not* do. Indeed, capability
systems have no binary distinction between "trusted" and "untrusted" code
(outside the system TCB, which is as small as possible); the only security
distinction between protection domains is in what capabilities they hold.

The main reason why capability systems do not have any such restriction is
that it reduces the system's ability to support fine-grained delegation of
authority. We want to be able to grant an object just the authority it needs
for any particular task. For that to work, code that is otherwise untrusted
must be able to use any capability it is given, even if it is a very powerful
capability, and therefore must be able to call into more-trusted code without
restriction.

To characterise this as "tricking" the more-trusted code is a misconception:
if it is not intended that a particular protection domain should have some
authority, then it should not be given a capability for that authority in
the first place. Capability-based security design emphasises preventing
protection domains from gaining unintended capabilities; it is not about
restricting their use once granted (except t

Re: [Python-Dev] Python 2.4, VS 2005 & Profile Guided Optmization

[Joe Smith]

"Joe Smith" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> "Neil Hodgson" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> Trent Nelson:
>>
>>> I ended up playing around with Profile Guided Optimization, running
>>> ``python.exe pystones.py'' to collect call-graph data after
>>> python.exe/Python24.dll had been instrumented, then recompiling with the
>>> optimizations fed back in.
>>
>>   It'd be an idea to build a larger body of Python code to run the
>> profiling pass on so it doesn't just optimize the sort of code in
>> pystone which is not very representative. Could run the test suite as
>> it would have good coverage but would hit exceptional cases too
>> heavily. Other compilers (Intel?) support profile directed
>> optimization so would also benefit from such a body of code.
>>
>
> GCC suppost profiling optimized code.
Err... That was supposed to say "supports profile-optimized code".
The rest of the message was indeed about Profile Guided Optimization in gcc.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setup.py and cross-compiling

[Martin v. Löwis]

Ed Swierk wrote:
> I decided to hack up setup.py so that an optional root directory (passed via 
> an
> environment variable) is prepended to all the hardcoded paths like
> "/usr/include", "/lib", "/lib64", and so on.

I doubt this solves the problem. Distutils just doesn't support
cross-compilation, period.

The main problem is that it is the host python that runs setup.py,
not the target python. Various parts of distutils assume that the
information the interpreter provides is correct, yet it is not
in a cross-compilation case.

I'm uncertain how to solve this; using a target Makefile and pyconfig.h
instead of the installed one might be a starting point. One should then
review distutils to find out where it accesses host information when
target information is required, and then find a way to come up with
that information. If no information is available, then distutils should
fail instead of returning incorrect information.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Document performance requirements?

[Scott Dial]

Between the two of you, I think you have made the case that the language 
specification is better to not include such details. As you both note, 
it is difficult to capture the essence of what is desired from the 
performance of the implementation. To tag on other version, what about 
Big-O space concerns with things like list.sort. I'm sure there are 
other things to add as well.

It seems reasonable to me that everyone has the same interests in mind 
when they write a program. Make it good, make it fast, make it small, 
etc. These sort of details should work themselves out if they are 
actually important. All of these algorithms should be treated as 
implementation accidents.

Having the information about CPython's implementation in the docs would 
be good. And go most of the way towards having everyone on the same page.

-- 
Scott Dial
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setup.py and cross-compiling

[Martin v. Löwis]

Ed Swierk wrote:
> Well, it seems buildroot solves this main problem by building another
> version of python and pygen that run on the build machine, and hacks
> the Makefile to run setup.py with these instead of whatever happens to
> be sitting in /usr/bin.

If you think its useful, please submit a patch to sf.net/projects/python
It would be good if you could get other people that attempt to
cross-build Python to comment. A detailed howto might help to get them
started with your code.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] new security doc using object-capabilities

[Greg Ewing]

Phillip J. Eby wrote:

> When I say "name checker" I mean the Zope type that allows you to specify a 
> list of names that are allowed for a given object.  This allowing is not 
> based on identity or code signing or anything like that.  It's just a list 
> of attribute names: i.e. a capability mask over an existing object.

But this is backwards from what a true object-capability
system should be like if it's properly designed. Instead
of starting with too-powerful objects and trying to
hide some of their powers, the different powers should
be separated into different objects in the first place.

It sounds to me like Zope is using the approach it's
using because it's having to work with Python as it
currently is, not because its approach is the best one.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Strategy for converting the decimal module to C

[Greg Ewing]

Nick Maclaren wrote:

> Er, no.  Try a machine-check in a TLB miss handler.  But it is all
> pretty irrelevant, as the problem arises with asychronous exceptions
> (e.g. timer interrupts, signals from other processes), anyway.

But we weren't talking about asynchronous exceptions,
we were talking about floating point exceptions. Unless
your TLB miss handler uses floating point arithmethic,
there's no way it can get interrupted by one. (And if
it does use floating point arithmetic in a way that
can cause an exception, you'd better write it to deal
with that!)

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] new security doc using object-capabilities

[Phillip J. Eby]

At 12:04 PM 7/25/2006 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
>
> > When I say "name checker" I mean the Zope type that allows you to 
> specify a
> > list of names that are allowed for a given object.  This allowing is not
> > based on identity or code signing or anything like that.  It's just a list
> > of attribute names: i.e. a capability mask over an existing object.
>
>But this is backwards from what a true object-capability
>system should be like if it's properly designed. Instead
>of starting with too-powerful objects and trying to
>hide some of their powers, the different powers should
>be separated into different objects in the first place.

And what about code that needs to pass on a subset of a capability?  You 
need the ability to create such capability-restricted subsets anyway, no 
matter how "pure" a system you start with.

And being able to create capability masks for existing objects means you 
don't have to redesign every piece of code ever written for Python to make 
it secure.


>It sounds to me like Zope is using the approach it's
>using because it's having to work with Python as it
>currently is, not because its approach is the best one.


Well, that depends a lot on how you define "best".  Practicality beats 
purity, doesn't it?  ;)

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] new security doc using object-capabilities

[David Hopwood]

Phillip J. Eby wrote:
> At 12:04 PM 7/25/2006 +1200, Greg Ewing wrote:
>>Phillip J. Eby wrote:
>>
>>>When I say "name checker" I mean the Zope type that allows you to specify
>>>a list of names that are allowed for a given object.  This allowing is not
>>>based on identity or code signing or anything like that.  It's just a list
>>>of attribute names: i.e. a capability mask over an existing object.
>>
>>But this is backwards from what a true object-capability
>>system should be like if it's properly designed. Instead
>>of starting with too-powerful objects and trying to
>>hide some of their powers, the different powers should
>>be separated into different objects in the first place.
> 
> And what about code that needs to pass on a subset of a capability?  You 
> need the ability to create such capability-restricted subsets anyway, no 
> matter how "pure" a system you start with.

That is true, but doing so for every secure object has significant costs.
A simple wrapper is not sufficient, because it would not prevent a wrapped
object from returning a reference to itself, bypassing the wrapper. To solve
this problem you need to use the more complex Membrane pattern, which also
wraps the results of method calls on a wrapped object, for example.

In fact Zope's approach does implement a membrane, but this does not really
dent the argument that Greg Ewing was making. A pure capability system incurs
the complexity and performance costs of wrappers or membranes only in cases
where they are needed, not for every object, and the complexity is only in
user code, not in the system's security kernel.

-- 
David Hopwood <[EMAIL PROTECTED]>


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] outstanding bugs to fix for 2.5

[Neal Norwitz]

There are still a bunch of outstanding bugs.  rc1 is about a week away
and it would be great to fix these.  Many of these are also present in
2.4, but it would be nice to squash them in 2.5.  Here's the list from
PEP 356:

http://python.org/sf/1526585 - SystemError concat long strings (2.4)
http://python.org/sf/1523610 - PyArg_ParseTupleAndKeywords potential
core dump (2.4)
http://python.org/sf/1521947 - mystrtol.c fails with gcc 4.1 (2.4?)
test_compile.test_unary_minus
http://python.org/sf/1519025 - socket timeout crash when receive
signal (2.4)
http://python.org/sf/1517042 - Fix crashers/gc_inspection.py (2.4)
http://python.org/sf/1515471 - stringobject (char buffers)
http://python.org/sf/1513611 - XML: xml.sax.expatreader missing
http://python.org/sf/1511497 - XML: xml.sax.ParseException issue
http://python.org/sf/1475523 - gettext.py bug
http://python.org/sf/1467929 - %-formatting and dicts (2.4)
http://python.org/sf/1333982 - AST
http://python.org/sf/1191458 - AST (test_trace issue mentioned below)

It would be great to fix *all* of these.  In this list, at least 3
(4?) can cause segfaults, and #1521947 can cause incorrect results.

n
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] remaining issues from Klocwork static analysis

[Neal Norwitz]

I've fixed most of the problems (or determined they weren't problems)
from all the warnings issued by Klocwork's static analysis tool.  The
following are outstanding issues.

This first group looks like real problems to me:

# 74 Object/funcobject.c:143Suspicious deref of ptr before NULL check
#169 Modules/threadmodule.c:497 Memory Leak

# 28 Modules/_sre.c:987   Array Index Out of Bounds

Buffer overflow, array index of 'mark' may be outside the
bounds. Array 'mark' of size 200 declared at sre.h:77 may use
index values 0..536870911. Also there are 3 similar errors on
lines 1006, 1225, 1237.  (Try limiting mark on line 589?)

#174 Modules/unicodedata.c:432   Array Index Out of Bounds

Buffer overflow, array index of 'decomp_prefix' may be outside the
bounds. Array 'decomp_prefix' of size 18 declared at
unicodedata_db.h:529 may use index values 18..255. Also there is one
similar error on line 433.

# 36 Modules/cPickle.c:3404   Memory Leak

Memory leak. Dynamic memory stored in 's' allocated through
function 'pystrndup' at line 3384 is lost at line 3404.

s should not be freed on line 3407, but earlier.
PDATA_PUSH can return on error and s will not be freed.

# 61 Modules/_sqlite/cursor.c:599  Null pointer may be dereferenced

Null pointer 'self->statement' that comes from line 674 may be
dereferenced by passing argument 1 to function
'statement_mark_dirty' at line 599.

Most of these seem suspect.  I'm not so sure about them, but I haven't
looked into some at all.  Let me know if you want the details for any
of these or if you can provide an analysis to demonstrate they are
incorrect.

Null pointer may be dereferencedPython/ast.c:641
Null pointer may be dereferencedPython/ast.c:656
Ptr will be derefed after it was positively checked for
NULLPython/compile.c:3020
Null pointer may be passed to function that may dereference
it  Python/compile.c:4459
Array Index Out of Bounds   Modules/_sre.c:987
Array Index Out of Bounds   Object/longobject.c:1787
Array Index Out of Bounds   Object/longobject.c:2475
Array Index Out of Bounds   Python/sysmodule.c:1016

Array Index Out of Bounds   Python/getpath.c:285
Buffer Overflow - Non-null Terminated StringPython/getpath.c:432
Unvalidated User Input Buffer Overflow-Non-Null Terminated
String  Python/getpath.c:431
Unvalidated User Input Buffer Overflow-Non-Null Terminated
String  Python/getpath.c:496
Unvalidated User Input Buffer Overflow-Non-Null Terminated
String  Python/getpath.c:497

Let me know if you want more info about any particular report.  It
would be great to have some help and fix these.

n
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] outstanding bugs to fix for 2.5

[Martin v. Löwis]

Neal Norwitz wrote:
> http://python.org/sf/1513611 - XML: xml.sax.expatreader missing
> 
> It would be great to fix *all* of these.  In this list, at least 3
> (4?) can cause segfaults, and #1521947 can cause incorrect results.

IMO, 1513611 should block the release, since it's a regression from 2.4
that may break many SAX applications, and perhaps also DOM applications.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com