I have a Python Product that I have mostly finished, and now I want to add security to it. I am importing Globals.InitializeCLass and AccessControl.ClassSecurityInfo. I am adding a ClassSecurityInfo instance in my class, and I am calling InitializeClass on my class at the bottom of the Module. I have run into the following problem: Classes in Python products that inherit from OFS.SimpleItem.SimpleItem or OFS.SimpleItem.Item have an attribute set: __allow_access_to_unprotected_subobjects__ = 1 This allows all class attributes and subobjects that are not explicitly private or protected by a permission to be accessed from the restricted code environment, or directly traversed into by a web browser. Supposedly, setting __allow_access_to_unprotected_subobjects__ = 0 inside your class will return the behaviour to the default (access not explicitly allowed is denied), but this doesn't seem to work for me. Adding explicit permissions to methods *does* work, but only for methods. Attributes such as dictionaries would be left unprotected. Can anyone suggest what I might be doing wrong? I am working with Zope 2.4 Thanks, Michael Bernstein.
Michael R. Bernstein writes:
... Classes in Python products that inherit from OFS.SimpleItem.SimpleItem or OFS.SimpleItem.Item have an attribute set:
__allow_access_to_unprotected_subobjects__ = 1
This allows all class attributes and subobjects that are not explicitly private or protected by a permission to be accessed from the restricted code environment, or directly traversed into by a web browser.
Supposedly, setting __allow_access_to_unprotected_subobjects__ = 0 inside your class will return the behaviour to the default (access not explicitly allowed is denied), but this doesn't seem to work for me. It should work.
Maybe "initializeClass" overwrites it again. Try to set it after the "initializeClass": initializeClass(klass) klass.__allow_access_to_unprotected_subobjects__ = 0 Dieter
On 31 Jul 2001 21:36:53 +0200, Dieter Maurer wrote:
Michael R. Bernstein writes:
... Supposedly, setting __allow_access_to_unprotected_subobjects__ = 0 inside your class will return the behaviour to the default (access not explicitly allowed is denied), but this doesn't seem to work for me.
It should work.
I know, <sigh>.
Maybe "initializeClass" overwrites it again. Try to set it after the "initializeClass":
initializeClass(klass) klass.__allow_access_to_unprotected_subobjects__ = 0
Thanks for the suggestion, but that still isn't it. Would you like to take a look at my code? Michael Bernstein.
Michael R. Bernstein writes:
On 31 Jul 2001 21:36:53 +0200, Dieter Maurer wrote:
It should work.
I know, <sigh>.
Maybe "initializeClass" overwrites it again. Try to set it after the "initializeClass":
initializeClass(klass) klass.__allow_access_to_unprotected_subobjects__ = 0
Thanks for the suggestion, but that still isn't it. Would you like to take a look at my code? Looking at the code is usually not enough for analysing difficult behavior (as yours seems to be). I fear, debugging will be necessary. I don't know, how easy it will be that you can downstrip your code in a way that it becomes debuggable in a standard installation...
Dieter
On 01 Aug 2001 20:12:02 +0200, Dieter Maurer wrote:
Michael R. Bernstein writes:
Thanks for the suggestion, but that still isn't it. Would you like to take a look at my code?
Looking at the code is usually not enough for analysing difficult behavior (as yours seems to be). I fear, debugging will be necessary.
I don't know, how easy it will be that you can downstrip your code in a way that it becomes debuggable in a standard installation...
This product is fairly simple. It consists of two classes, one derived from SimpleItem is a 'container' and uses __getitem__ to traverse into instances of a second class (derived from item) in a dict. there are various forms and form processing methods, but *none* of them should be accessible by default. I have deliberately not added any security assertions to the classes beyond what should be neccessary to activate the default policy (deny if not allowed). If this was working correctly, I would expect no access to be possible to instances of my Product, it's subobjects, or its attributes. Since this is not the case, I am becoming more convinced that something is broken here. Anyway, if anyone wants to have a crack at the code, I'll send it over. Thanks, Michael Bernstein.
Supposedly, setting __allow_access_to_unprotected_subobjects__ = 0
I **might** have found an answer to this: Found here: http://www.zope.org/Members/karl/MyWiki/PublishNotes " - tries to get __allow_access_to_unprotected_subobjects__ if not there this can be true, in which case access is granted, or a dict, in which case we grant if the value for the key of the object's name is true, or a callable object, in which case we grant if the function called with the name and the value (?) returns true." Seems that "__allow_access_to_unprotected_subobjects__ = 0" is wrong. It should either be "1" or a dictionary of permissions ... Does that help a bit? Joachim
On 01 Aug 2001 20:01:12 +0200, Joachim Werner wrote:
Supposedly, setting __allow_access_to_unprotected_subobjects__ = 0
I **might** have found an answer to this:
Found here: http://www.zope.org/Members/karl/MyWiki/PublishNotes
" - tries to get __allow_access_to_unprotected_subobjects__ if not there
this can be true, in which case access is granted, or a dict, in which case we grant if the value for the key of the object's name is true, or a callable object, in which case we grant if the function called with the name and the value (?) returns true."
Seems that "__allow_access_to_unprotected_subobjects__ = 0" is wrong. It should either be "1" or a dictionary of permissions ...
<expletive deleted>! No wonder it wasn't working! If I have this right, setting __allow_access_...etc to an empty dict should work, right? Michael Bernstein
On 01 Aug 2001 20:01:12 +0200, Joachim Werner wrote:
Supposedly, setting __allow_access_to_unprotected_subobjects__ = 0
I **might** have found an answer to this: [snip] Seems that "__allow_access_to_unprotected_subobjects__ = 0" is wrong. It should either be "1" or a dictionary of permissions ...
Does that help a bit?
Ok, so I tried to set '__allow_access_to_unprotected_subobjects__ = {}' in the class, but this *still* has no effect. I could try combining this with Dieter's suggestion... Michael Bernstein.
On 01 Aug 2001 13:01:21 -0700, Michael R. Bernstein wrote:
On 01 Aug 2001 20:01:12 +0200, Joachim Werner wrote:
Supposedly, setting __allow_access_to_unprotected_subobjects__ = 0
I **might** have found an answer to this: [snip] Seems that "__allow_access_to_unprotected_subobjects__ = 0" is wrong. It should either be "1" or a dictionary of permissions ...
Does that help a bit?
Ok, so I tried to set '__allow_access_to_unprotected_subobjects__ = {}' in the class, but this *still* has no effect.
Correction: This *does* disallow access to attributes and methods from unrestricted code, ie: <dtml-with TestInstance> <dtml-var method> </dtml-with> raises an unauthorized exception (progress!). However, *traversing* to the unprotected methods is still being alowed, where I'm fairly certain that it shouldn't be. The only thing I'm doing with traversal (assuming that my code is at fault here) is the following: def __getitem__(self, id): return self.Entries[id].__of__(self) Entries is a dictionary that uses id as a key, and instances of my EntryClass as values. Could this be screwing with the security somehow, and allowing access to unprotected methods of my main class? Thanks for the help, michael Bernstein.
On 01 Aug 2001 13:32:21 -0700, Michael R. Bernstein wrote:
On 01 Aug 2001 13:01:21 -0700, Michael R. Bernstein wrote:
On 01 Aug 2001 20:01:12 +0200, Joachim Werner wrote:
Supposedly, setting __allow_access_to_unprotected_subobjects__ = 0
I **might** have found an answer to this: [snip] Seems that "__allow_access_to_unprotected_subobjects__ = 0" is wrong. It should either be "1" or a dictionary of permissions ...
Does that help a bit?
Ok, so I tried to set '__allow_access_to_unprotected_subobjects__ = {}' in the class, but this *still* has no effect.
Correction: This *does* disallow access to attributes and methods from unrestricted code, ie:
<dtml-with TestInstance> <dtml-var method> </dtml-with>
raises an unauthorized exception (progress!). However, *traversing* to the unprotected methods is still being alowed, where I'm fairly certain that it shouldn't be.
Another correction <sigh>: I had a sneaking suspicion, so I went back and set '__allow_access_to_unprotected_subobjects__ = 0' again. Guess what, acces from restricted code is *not* being allowed <sigh>. So, Chris' sugestion was correct, after all. Well, I apologize if this has confused people. I simply assumed that if I could traverse to a method, then it was also accessible from restricted code (I'm not 100% certain that this wasn't a valid assumption). So, something wierd is happening WRT traversal here, whether it's a bug in Zope or my code. Anyone have suggestions on investigating further? Thanks, Michael Bernstein.
Michael R. Bernstein writes:
The only thing I'm doing with traversal (assuming that my code is at fault here) is the following:
def __getitem__(self, id): return self.Entries[id].__of__(self)
Entries is a dictionary that uses id as a key, and instances of my EntryClass as values.
Could this be screwing with the security somehow, and allowing access to unprotected methods of my main class? It seems to be part of your Python class code...
If this is the case, security checks are disabled for the access (no security checks in External Methods and Python products). There may be checks again, if you access the returned object from DTML/Python Script or other TTW editable objects. Dieter
participants (3)
-
Dieter Maurer -
Joachim Werner -
Michael R. Bernstein