March 2001 - Zope-Dev

Zope 2.3.0 AccessControl/SecurityInfo.py
by Randall F. Kern 01 Mar '01

01 Mar '01

Sorry if these have already been fixed in 2.3.1, I haven't had time to upgrade yet. I fixed a small bug in SecurityInfo that made SecurityInfo.setPermissionDefault() impossible to use: 191c191 > self.roles[permission_name] = rdict.keys() --- < self.roles[permission_name] = rdict def setPermissionDefault(self, permission_name, roles): """Declare default roles for a permission""" rdict = {} for role in roles: rdict[role] = 1 if self.roles.get(permission_name, rdict) != rdict: LOG('SecurityInfo', WARNING, 'Conflicting default role' 'declarations for permission "%s"' % permission_name) self._warnings = 1 self.roles[permission_name] = rdict.keys() My other problem was that I wanted to setup some default permissions that are used programatically in my product (i.e. they aren't used to protect any specific methods, but the methods themselves check for the permission.) A small change to ClassSecurityInfo.apply() allows you to call SecurityInfo.setPermissionDefault() to create new permissions, even if they aren't attached to any methods: 239a240,242 > for permission_name in self.roles.keys(): > if not ac_permissions.has_key(permission_name): > ac_permissions[permission_name] = () def apply(self, classobj): """Apply security information to the given class object.""" dict = classobj.__dict__ # Check the class for an existing __ac_permissions__ and # incorporate that if present to support older classes or # classes that haven't fully switched to using SecurityInfo. if dict.has_key('__ac_permissions__'): for item in dict['__ac_permissions__']: permission_name = item[0] self._setaccess(item[1], permission_name) if len(item) > 2: self.setDefaultRoles(permission_name, item[2]) # Set __roles__ for attributes declared public or private. # Collect protected attribute names in ac_permissions. ac_permissions = {} for name, access in self.names.items(): if access in (ACCESS_PRIVATE, ACCESS_PUBLIC, ACCESS_NONE): dict['%s__roles__' % name] = access else: if not ac_permissions.has_key(access): ac_permissions[access] = [] ac_permissions[access].append(name) # Now transform our nested dict structure into the nested tuple # structure expected of __ac_permissions__ attributes and set # it on the class object. getRoles = self.roles.get __ac_permissions__ = [] for permission_name in self.roles.keys(): if not ac_permissions.has_key(permission_name): ac_permissions[permission_name] = () permissions = ac_permissions.items() permissions.sort() for permission_name, names in permissions: roles = getRoles(permission_name, ()) if len(roles): entry = (permission_name, tuple(names), tuple(roles)) else: entry = (permission_name, tuple(names)) __ac_permissions__.append(entry) dict['__ac_permissions__'] = tuple(__ac_permissions__) # Take care of default attribute access policy access = getattr(self, 'access', _marker) if access is not _marker: dict['__allow_access_to_unprotected_subobjects__'] = access if getattr(self, '_warnings', None): LOG('SecurityInfo', WARNING, 'Class "%s" had conflicting ' 'security declarations' % classobj.__name__) -Randy

1 0

CopySupport issues
by richard＠bizarsoftware.com.au 01 Mar '01

01 Mar '01

These comments are against the CVS of about a week ago. I can't get to the CVS to update at the moment - the connection times out. Is there a reason why the manage_main call at the end of manage_copyObjects and manage_cutObjects in CopySupport gets called as self.manage_main(REQUEST) instead of self.manage_main(self, REQUEST)? Using the first form, we found that the manage_main call was dying because it couldn't acquire various attributes and methods it needed (eg, manage_page_header :). The second form just makes sense... In the Copy operation of manage_pasteObjects, the manage_afterClone is called before the object is added to its container. We'd much prefer the object to be both added to the container and re-got so it the manage_afterClone call may make use of acquired information. This is of use specifically for us so that the object may determine its new URL and catalog itself with our (Z)Catalog. Interestingly, a call to absolute_url() on the object breaks because self.REQUEST is '<Special Object Used to Force Acquisition>' (yes, a string). Buggered if I know where that came from (actually, I know it originates in Acquisition.c, but that's a scary, scary place :) Richard -- Richard Jones richard(a)bizarsoftware.com.au Senior Software Developer, Bizar Software (www.bizarsoftware.com.au)

1 1

Increased system CPU cycles under heavy load?
by Erik Stephens 01 Mar '01

01 Mar '01

Hello all, I apologize if this might be more appropriate for a Linux list. From our time-series graphs, we are noticing that the percentage of CPU cycles spent on 'system' tasks grows considerably under heavy load. Does anyone know what kinds of operations fall under 'system'? Task switching, paging, these kinds of things? When load is light, it appears that the same 1 or 2 Zope threads will handle the requests. As load increases, then more threads get into the mix. How likely is it that this increase in 'system' CPU cycles is stemming from having to switch between the Zope threads? Perhaps Zope goes into a near dead-lock state and starts to spend a bunch of time waiting for other threads to release a lock? The reason I mention this is that we don't notice the increased amount of 'system' CPU when the load increases on other servers (Apache, MySQL) on other machines. System info: Zope 2.1.6, Redhat 6.2, PC arch Thanks, Erik

1 0

REQUEST.steps
by Chris Withers 01 Mar '01

01 Mar '01

Is it alright to rely on this attribute of the REQUEST object? If so, is it affected by virtual hosting? cheers, Chris

4 4