[Zope-dev] PAS and AccessControl bug?

2011-12-29 Thread Martin Aspeli
Hi,

I found this code in PAS, which is mostly lifted from AccessControl.userfolder:

def _getObjectContext( self, v, request ):

 request - ( a, c, n, v )

o 'a 'is the object the object was accessed through

o 'c 'is the physical container of the object

o 'n 'is the name used to access the object

o 'v' is the object (value) we're validating access to

o XXX:  Lifted from AccessControl.User.BasicUserFolder._getobcontext

if len( request.steps ) == 0: # someone deleted root index_html

request[ 'RESPONSE' ].notFoundError(
'no default view (root default view was probably deleted)' )

root = request[ 'PARENTS' ][ -1 ]
request_container = aq_parent( root )

n = request.steps[ -1 ]

# default to accessed and container as v.aq_parent
a = c = request[ 'PARENTS' ][ 0 ]

# try to find actual container
inner = aq_inner( v )
innerparent = aq_parent( inner )

if innerparent is not None:

# this is not a method, we needn't treat it specially
c = innerparent

elif hasattr(v, 'im_self'):

# this is a method, we need to treat it specially
c = v.im_self
c = aq_inner( v )

# if pub's aq_parent or container is the request container, it
# means pub was accessed from the root
if a is request_container:
a = root

if c is request_container:
c = root

return a, c, n, v

Look at this bit again:


elif hasattr(v, 'im_self'):

# this is a method, we need to treat it specially
c = v.im_self
c = aq_inner( v )

In AccessControl, it's similar:

elif hasattr(v, 'im_self'):
# this is a method, we need to treat it specially
c = v.im_self
c = getattr(v, 'aq_inner', v)

Surely, this isn't right? What is the correct thing to do here?

Martin
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] ZopeSecurityPolicy global manipulation

2011-12-29 Thread Martin Aspeli
Hi,

AccessControl.ZopeSecurityPolicy contains this code:

from types import MethodType

# AccessControl.Implementation inserts:
#   ZopeSecurityPolicy, getRoles, rolesForPermissionOn
from AccessControl.SimpleObjectPolicies import _noroles

rolesForPermissionOn = None  # XXX:  avoid import loop

tuple_or_list = tuple, list


def getRoles(container, name, value, default):

global rolesForPermissionOn  # XXX:  avoid import loop

if rolesForPermissionOn is None:
from PermissionRole import rolesForPermissionOn

roles = getattr(value, '__roles__', _noroles)
if roles is _noroles:
if not name or not isinstance(name, basestring):
return default

if type(value) is MethodType:
container = value.im_self

cls = getattr(container, '__class__', None)
if cls is None:
return default

roles = getattr(cls, name+'__roles__', _noroles)
if roles is _noroles:
return default

value = container

if roles is None or isinstance(roles, tuple_or_list):
return roles

rolesForPermissionOn = getattr(roles, 'rolesForPermissionOn', None)
if rolesForPermissionOn is not None:
roles = rolesForPermissionOn(value)

return roles

Look carefully at how ``rolesForPermissionOn`` is used both at the
top, to lazily set a global to avoid an import loop, and the bottom,
as an attribute of the ``roles`` object.

I'm pretty sure this is wrong™ on many levels, but most importantly,
it seems the global is being overwritten each time execution gets down
to that last block. I know this module gets munged by Implementation,
but I'm pretty sure ImplPython doesn't define getRoles() at least, and
I'm not even sure the C implementation does either.

To prove it to myself, I made a frivolous equivalent that used
'datetime.date' as the importable. It's a bit ugly, but you get the
idea:

 date = None
 class C(object):
... def __init__(self, d):
... self.date = d
...
 c1 = C(lambda: 'x')
 c2 = C(lambda: 'y')
 def get(c):
... global date
... if date is None:
... from datetime import date
... date = getattr(c, 'date', None)
... if date is not None:
... print date()
...
 date is None
True
 get(c1)
x
 date
function lambda at 0x10dac8140
 get(c2)
y
 date
function lambda at 0x10dac8cf8


Surely, this is all evil volatile? Maybe the global bit just needs to
go away? It doesn't seem to be used in that function, and I'm pretty
sure the implementation ends up overwriting the global anyway.

Cheers,
Martin
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] zope-tests - FAILED: 2, OK: 39

2011-12-29 Thread Zope tests summarizer
This is the summary for test reports received on the 
zope-tests list between 2011-12-28 00:00:00 UTC and 2011-12-29 00:00:00 UTC:

See the footnotes for test reports of unsuccessful builds.

An up-to date view of the builders is also available in our 
buildbot documentation: 
http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds

Reports received


   Bluebream / Python2.5.5 64bit linux
   Bluebream / Python2.6.7 64bit linux
   Bluebream / Python2.7.2 64bit linux
   ZTK 1.0 / Python2.4.6 Linux 64bit
   ZTK 1.0 / Python2.5.5 Linux 64bit
   ZTK 1.0 / Python2.6.7 Linux 64bit
   ZTK 1.0dev / Python2.4.6 Linux 64bit
   ZTK 1.0dev / Python2.5.5 Linux 64bit
   ZTK 1.0dev / Python2.6.7 Linux 64bit
   ZTK 1.1 / Python2.5.5 Linux 64bit
   ZTK 1.1 / Python2.6.7 Linux 64bit
   ZTK 1.1 / Python2.7.2 Linux 64bit
   ZTK 1.1dev / Python2.5.5 Linux 64bit
   ZTK 1.1dev / Python2.6.7 Linux 64bit
[1]ZTK 1.1dev / Python2.7.2 Linux 64bit
   Zope 3.4 KGS / Python2.4.6 64bit linux
   Zope 3.4 KGS / Python2.5.5 64bit linux
   Zope 3.4 Known Good Set / py2.4-32bit-linux
   Zope 3.4 Known Good Set / py2.4-64bit-linux
   Zope 3.4 Known Good Set / py2.5-32bit-linux
   Zope 3.4 Known Good Set / py2.5-64bit-linux
   Zope Buildbot / zope2.12-py2.6 slave-ubuntu64
   Zope Buildbot / zope2.13-py2.6 slave-ubuntu64
   Zope Buildbot / zope2.13-py2.7 slave-ubuntu64
   Zope Buildbot / zope2.14-py2.6 slave-ubuntu64
   Zope Buildbot / zope2.14-py2.7 slave-ubuntu64
   Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu64
   Zope Buildbot / zopetoolkit-1.0-py2.5 slave-ubuntu64
   Zope Buildbot / zopetoolkit-1.0-py2.6 slave-ubuntu64
   Zope Buildbot / zopetoolkit-1.1-py2.5 slave-ubuntu64
   Zope Buildbot / zopetoolkit-1.1-py2.6 slave-ubuntu64
[2]Zope Buildbot / zopetoolkit-py2.5 slave-ubuntu64
   Zope Buildbot / zopetoolkit-py2.6 slave-ubuntu64
   Zope-2.10 Python-2.4.6 : Linux
   Zope-2.11 Python-2.4.6 : Linux
   Zope-2.12 Python-2.6.6 : Linux
   Zope-2.12-alltests Python-2.6.6 : Linux
   Zope-2.13 Python-2.6.6 : Linux
   Zope-2.13-alltests Python-2.6.6 : Linux
   Zope-trunk Python-2.6.6 : Linux
   Zope-trunk-alltests Python-2.6.6 : Linux

Non-OK results
--

[1]FAILED  ZTK 1.1dev / Python2.7.2 Linux 64bit
   https://mail.zope.org/pipermail/zope-tests/2011-December/054973.html


[2]FAILED  Zope Buildbot / zopetoolkit-py2.5 slave-ubuntu64
   https://mail.zope.org/pipermail/zope-tests/2011-December/055000.html


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )