Re: [Zope-dev] Security Gurus Wanted
Just a word to thank you for your reply. But incidently, wouldn't it be a good idea for Globals.InitializeClass() to throw an error or a warning of some kind for hanging 'security.stuff()' declarations, declarations which do not have a related ClassSecurityInfo object AT THE CLASS LEVEL? To the unaware beginner (like myself) this creates a very obscure bug: the declaration at the module level 'hiding' the missing ClassSecurityInfo object (at the class level). I see some other discussions on this list on this topic, so maybe this problem is already being addressed. Anyway, I would never have found this alone by a long shot. Thanks. Sorry for the cross-post. * Steve Alexander [EMAIL PROTECTED] [020118 15:43]: vio wrote: Could someone have a look at the following 'Boring' class with the security functionality added (as described in ZopeBook/6.Security and some other products). Could 'security' machinery be broken in Zope-2.4.1 ? It surely doesn't seem to work as adverised, on my machine at least (Debian Linux 2.2, Zope 2.4.1 (source release) python 2.1.0, linux2). Tell me if it works on your installation. Boring.py __doc__ = __version__ = '0.1' import Globals from Globals import HTMLFile # fakes a method from a DTML file from Globals import MessageDialog # provid from Globals import Persistent# makes an object stick in the ZODB import OFS.SimpleItem import Acquisition import AccessControl.Role from AccessControl import ClassSecurityInfo READ_PERM = 'View Stuff' WRITE_PERM = 'Change Stuff' security = ClassSecurityInfo() You have declared your ClassSecurityInfo object at the module level, rather than as an attribute of the class you wish to make security statements about. Please do not cross-post to both [EMAIL PROTECTED] and [EMAIL PROTECTED] Post to one or the other. -- Steve Alexander ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Security Gurus Wanted
vio wrote: Just a word to thank you for your reply. But incidently, wouldn't it be a good idea for Globals.InitializeClass() to throw an error or a warning of some kind for hanging 'security.stuff()' declarations, declarations which do not have a related ClassSecurityInfo object AT THE CLASS LEVEL? That would be a fine idea. Unfortunately, there is no straightforward way telling that you called methods on the security object in the class definition. When you call Globals.InitializeClass(your_class), it looks for a ClassSecurityInfo object, and doesn't find one. The fact that your class definition had the side-effect of altering the module's security object doesn't leave any traces in the class object that results from your definition. -- Steve Alexander ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Security Gurus Wanted
* vio [EMAIL PROTECTED] [020119 09:56]: vio wrote: Just a word to thank you for your reply. But incidently, wouldn't it be a good idea for Globals.InitializeClass() to throw an error or a warning of some kind for hanging 'security.stuff()' declarations, declarations which do not have a related ClassSecurityInfo object AT THE CLASS LEVEL? That would be a fine idea. Unfortunately, there is no straightforward way telling that you called methods on the security object in the class definition. Why not simply check for the keyword 'security.' in the class source ? Anything beginning with that word most probably has something to do with security. But if 'security' is not a reference to a security object, just throw an exception. This would make everything so much simpler. When you call Globals.InitializeClass(your_class), it looks for a ClassSecurityInfo object, and doesn't find one. If I understood correctly, this should be treated like an error: not allow the programmer to have calls to security methods which aren't there, because that's more or less what's happening here. And definitely not be silent about it !!! That's a syntax error or something. So Globals.InitializeClass(your_class) finds the declaration 'security.declareSomething()' inside a class, but 'security' being a reference to a ClassSecurityInfo object AT THE MODULE LEVEL somehow has no effect at the class level (while I wrongly thought that by declaring it at the module level like that, it will behave more or less like a 'global' variable). I wonder what was carried at the class level, but something definitely was, else Python would have thrown something ugly at me. In my opinion, Globals.InitializeClass() should check such calls to security methods, and by all means NOT remain silent if it can not carry out the call because it couldn't find a ClassSecurityInfo object's method. Throw a 'method not found' error or something like that. Silence = 'bad'. I'll even say it's a bug. Vio ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Security Gurus Wanted
vio wrote: deletia So Globals.InitializeClass(your_class) finds the declaration 'security.declareSomething()' inside a class, but 'security' being a reference to a ClassSecurityInfo object AT THE MODULE LEVEL somehow has no effect at the class level (while I wrongly thought that by declaring it at the module level like that, it will behave more or less like a 'global' variable). deletia In my opinion, Globals.InitializeClass() should check such calls to security methods You appear not to understand how Python and the declarative security system in Zope work. Globals.InitializeClass() does not read the source to your modules. You would need some sort of lint tool to perform the checking you describe. Why not try to implement a simple case of the error-correcting system that you describe? You might want to extend an existing lint tool such as PyChecker, to take account of conventions used in Zope products. http://pychecker.sourceforge.net/ -- Steve Alexander ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Security Gurus Wanted
You are right, I struggled a lot to understand Zope's declarative security model. And I am still learning, so practice makes better. I didn't read Globals.InitializeClass() source, and I wrote my following comments out of the blue. Developping an error-correcting system might still be a little out of my league, for now. Anyway, the important thing is that your initial comments regarding Boring.py were right on target: 'security = ClassSecurityInfo()' must be declared INSIDE the class. It really solved my problem. Thanks again !!! Cheers, Vio * Steve Alexander [EMAIL PROTECTED] [020119 11:05]: vio wrote: deletia So Globals.InitializeClass(your_class) finds the declaration 'security.declareSomething()' inside a class, but 'security' being a reference to a ClassSecurityInfo object AT THE MODULE LEVEL somehow has no effect at the class level (while I wrongly thought that by declaring it at the module level like that, it will behave more or less like a 'global' variable). deletia In my opinion, Globals.InitializeClass() should check such calls to security methods You appear not to understand how Python and the declarative security system in Zope work. Globals.InitializeClass() does not read the source to your modules. You would need some sort of lint tool to perform the checking you describe. Why not try to implement a simple case of the error-correcting system that you describe? You might want to extend an existing lint tool such as PyChecker, to take account of conventions used in Zope products. http://pychecker.sourceforge.net/ -- Steve Alexander ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Security Gurus Wanted
At 10:43 AM 1/19/02 -0500, vio wrote: * vio [EMAIL PROTECTED] [020119 09:56]: So Globals.InitializeClass(your_class) finds the declaration 'security.declareSomething()' inside a class, but 'security' being a reference to a ClassSecurityInfo object AT THE MODULE LEVEL somehow has no effect at the class level (while I wrongly thought that by declaring it at the module level like that, it will behave more or less like a 'global' variable). I wonder what was carried at the class level, but something definitely was, else Python would have thrown something ugly at me. Check the Python reference manual -- not the library reference, but the language definition. You'll find that Python has two primary scopes: local and global. When a class statement is executing, the local namespace is the future __dict__ of the class, and the global namespace is the module __dict__. If security.Foo() is in the body of a class, and security is not in the *local* namespace (i.e. already defined in the class body), then it will be looked up in the global namespace. Thus, your calls went to the module-level security, but no security object was present in the resulting class (because there was no statement placing one there). IMHO, you don't want to share a security object between more than one class, since presumably they will have different declarations and thus each require their own. So there's no reason to create a ClassSecurityInfo object at the module level, anyway. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Security Gurus Wanted
* Phillip J. Eby [EMAIL PROTECTED] [020119 12:04]: ... IMHO, you don't want to share a security object between more than one class, since presumably they will have different declarations and thus each require their own. So there's no reason to create a ClassSecurityInfo object at the module level, anyway. Good point. Actually, I only declared ClassSecurityInfo object at the module level out of convenience: I thought each class (presuming there were more than one in the module) could reference that same security object, so maybe save a few CPU cycles in the process (plus, I saw this done in some product I used as a learning example). But your point is well taken ... plus module-level security declarations have no effect at the class level. Vio ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Security Gurus Wanted
Could someone have a look at the following 'Boring' class with the security
functionality added (as described in ZopeBook/6.Security and some other products).
Could 'security' machinery be broken in Zope-2.4.1 ? It surely doesn't seem to work as
adverised, on my machine at least (Debian Linux 2.2, Zope 2.4.1 (source release)
python 2.1.0, linux2). Tell me if it works on your installation.
Boring.py
__doc__ =
__version__ = '0.1'
import Globals
from Globals import HTMLFile # fakes a method from a DTML file
from Globals import MessageDialog # provid
from Globals import Persistent# makes an object stick in the ZODB
import OFS.SimpleItem
import Acquisition
import AccessControl.Role
from AccessControl import ClassSecurityInfo
READ_PERM = 'View Stuff'
WRITE_PERM = 'Change Stuff'
security = ClassSecurityInfo()
manage_addBoringForm = HTMLFile('boringAdd', globals())
def manage_addBoring(self, id, title='', REQUEST=None):
Add a Boring to a folder.
self._setObject(id, Boring(id, title))
if REQUEST is not None:
return self.manage_main(self, REQUEST)
class Boring(
OFS.SimpleItem.Item, # A simple Principia object. Not Folderish.
Persistent,# Make us persistent. Yaah!
Acquisition.Implicit, # Uh, whatever.
AccessControl.Role.RoleManager # Security manager.
):
Boring object.
meta_type = 'Boring' # what do people think they're adding?
manage_options = ( # what management options are there?
{'label': 'Edit', 'action': 'manage_main'},
{'label': 'View', 'action': ''}, # defaults to index_html
{'label': 'Security', 'action': 'manage_access'},
)
# NOTE: commented out following as it seem to conflict with
# 'security.declareP...()' declarations later on
#__ac_permissions__=( # what permissions make sense for us?
# ('View management screens', ('manage_tabs','manage_main')),
# ('Change permissions', ('manage_access',) ),
# ('Change Borings' , ('manage_edit',) ),
# ('View Borings',('',)),
# )
def __init__(self, id, title=''):
initialise a new instance of Boring
self.id = id
self.title = title
# SECURITY -
# here I played with '#'s, then simply tried to access 'index_html'
# after each security declaration,
# as user 'Anonymous', and noted the results on same line.
# 'NOT-WORKING' simply means not working as advertised (allowed access when
# it shouldn't, and vice-versa). As you can see, there are too many
# 'NOT-WORKING' results. Do you come to similar results?
# My conclusion is that security declarations have no effect whatsoever,
# whether I declare something, then its oposite, I end up with the same
# result. This shouldn't be.
security.setPermissionDefault(READ_PERM,
['Stuff Manager','Manager'])
security.setDefaultAccess('deny') # == NOT-WORKING
# security.declarePrivate('index_html') # == NOT-WORKING
# security.declarePublic('index_html')# == OK
# security.declareProtected(READ_PERM, 'index_html') # == NOT-WORKING
index_html = HTMLFile('index', globals())
security.declarePublic('manage_main') # == NOT-WORKING
manage_main = HTMLFile('boringEdit', globals())
def manage_edit(self, title, REQUEST=None):
self.title = title
if REQUEST is not None:
return MessageDialog(
title = 'Edited',
message = Properties for %s changed. % self.id,
action = './manage_main',
)
Globals.InitializeClass(Boring)
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
