Problems with removing Verbose Security and possibly Apelib
We've run into a very strange situation. We been running zope 2.7.3 with Abelib 1.0 and Verbose Security 0.6. Verbose Security is great during development, but it does cause somewhat of a performance hit on a live server. So, recently after profiling our app in zope and finding that Verbose Security was eating a fair amount of time, I decided to try and remove it on our production systems. I removed the Verbose Security from the products directory and from the Products list in the control panel and tried the app again. Unfortunately, this causes the app to break. What appears to happen is that on any object we have used proxy settings on, when run without verbose security, we get a security error. If I go into that object on to the proxy tab, the roles are still selected and clicking update (with making no other changes), "fixes" the problem for a user. What is even weirder is that because we are using apelib, it is easy to see the changes made to the object when we make changes in the zmi. In this particular instance, we can see that even though the object was saved in the ZMI, and the files on disk were modified, the contents of the objects did not change when we updated the proxy settings, yet zope now appears to obey them. The last piece of the puzzle is that returning the VerboseSecurity product allows the application to start working again, proxy roles and all. Any ideas as to why this might be? Is there a chance that the monkey patching Verbose Security does is not reversible? Or is there some weird problem caused by using Verbose Security and Apelib? Thanks for your time, -Chris --- Error example Error Type: Unauthorized Error Value: You are not allowed to access 'select' in this context ...last lines in traceback # PythonScript at /somefunction> Line 3 # Module Shared.DC.Scripts.Bindings, line 178, in __getattr__ Unauthorized: You are not allowed to access 'select' in this context
Chris Kratz wrote at 2005-2-11 12:39 -0500:
... I removed the Verbose Security from the products directory and from the Products list in the control panel and tried the app again.
Unfortunately, this causes the app to break. ... The last piece of the puzzle is that returning the VerboseSecurity product allows the application to start working again, proxy roles and all. Any ideas as to why this might be? Is there a chance that the monkey patching Verbose Security does is not reversible?
Monkey patches should modify only non persistent objects (such as classes or modules). This means: their effect disappears when the process stops... Debugging might be necessary to understand this puzzle. By the way, I had the impression that VerboseSecurity becomes ineffective as soon as you switch to "security-policy" "C" rather than "python" (but I may well be wrong).
Error Type: Unauthorized Error Value: You are not allowed to access 'select' in this context
...last lines in traceback # PythonScript at /somefunction> Line 3 # Module Shared.DC.Scripts.Bindings, line 178, in __getattr__ Unauthorized: You are not allowed to access 'select' in this context
This exception comes from an "UnauthorizedBinding". It indicates that you try to access a binding ("context", "container", "here", ...) your script does not have rights to. This security tighening was introduced quite late (to fix a security bug). "VerboseSecurity" may be able to disable this tighening. Maybe, the tighening forgets to take proxy roles into account. But this is only a guess. Almost surely, you must debug the situation... -- Dieter
On Saturday 12 February 2005 02:18 pm, Dieter Maurer wrote:
Chris Kratz wrote at 2005-2-11 12:39 -0500:
... I removed the Verbose Security from the products directory and from the Products list in the control panel and tried the app again.
Unfortunately, this causes the app to break. ... The last piece of the puzzle is that returning the VerboseSecurity product allows the application to start working again, proxy roles and all. Any ideas as to why this might be? Is there a chance that the monkey patching Verbose Security does is not reversible?
... By the way, I had the impression that VerboseSecurity becomes ineffective as soon as you switch to "security-policy" "C" rather than "python" (but I may well be wrong).
Thanks for the response Dieter. Just as a response to your statement above, in my own testing here, if I set security-policy-implementation C in my zope.conf, I am still seeing lines for Verbose security in the profile information. Here is an example. ncalls tottime percall cumtime percall filename:lineno(function) 19567 0.740 0.000 10.300 0.001 VerboseSecurityPolicy.py:57 (validate) So it appears to me that Verbose Security overrides the security-policy-implementation setting in the zope.conf file.
Error Type: Unauthorized Error Value: You are not allowed to access 'select' in this context
...last lines in traceback # PythonScript at /somefunction> Line 3 # Module Shared.DC.Scripts.Bindings, line 178, in __getattr__ Unauthorized: You are not allowed to access 'select' in this context
This exception comes from an "UnauthorizedBinding". It indicates that you try to access a binding ("context", "container", "here", ...) your script does not have rights to.
This security tighening was introduced quite late (to fix a security bug). "VerboseSecurity" may be able to disable this tighening.
Maybe, the tighening forgets to take proxy roles into account. But this is only a guess. Almost surely, you must debug the situation...
I agree, it looks like further debuging will be required. What is so odd to us, is that visiting the ZMI, going to the proxy page on the affected object and re-saving it fixes the problem. This makes the proxy settings "stick" even though the settings do not appear to be lost. We can see in the properties file on the file system that the proxy settings are there. Perhaps there is a bug in how Apelib loads proxy settings when it pulls an object from the file system. -Chris
On Tuesday 15 February 2005 09:49 am, Chris Kratz wrote:
On Saturday 12 February 2005 02:18 pm, Dieter Maurer wrote:
Chris Kratz wrote at 2005-2-11 12:39 -0500:
... I removed the Verbose Security from the products directory and from the Products list in the control panel and tried the app again.
Unfortunately, this causes the app to break. ... The last piece of the puzzle is that returning the VerboseSecurity product allows the application to start working again, proxy roles and all. Any ideas as to why this might be? Is there a chance that the monkey patching Verbose Security does is not reversible?
... By the way, I had the impression that VerboseSecurity becomes ineffective as soon as you switch to "security-policy" "C" rather than "python" (but I may well be wrong).
Thanks for the response Dieter. Just as a response to your statement above, in my own testing here, if I set security-policy-implementation C in my zope.conf, I am still seeing lines for Verbose security in the profile information. Here is an example.
ncalls tottime percall cumtime percall filename:lineno(function) 19567 0.740 0.000 10.300 0.001 VerboseSecurityPolicy.py:57 (validate)
So it appears to me that Verbose Security overrides the security-policy-implementation setting in the zope.conf file.
Error Type: Unauthorized Error Value: You are not allowed to access 'select' in this context
...last lines in traceback # PythonScript at /somefunction> Line 3 # Module Shared.DC.Scripts.Bindings, line 178, in __getattr__ Unauthorized: You are not allowed to access 'select' in this context
This exception comes from an "UnauthorizedBinding". It indicates that you try to access a binding ("context", "container", "here", ...) your script does not have rights to.
This security tighening was introduced quite late (to fix a security bug). "VerboseSecurity" may be able to disable this tighening.
Maybe, the tighening forgets to take proxy roles into account. But this is only a guess. Almost surely, you must debug the situation...
I agree, it looks like further debuging will be required. What is so odd to us, is that visiting the ZMI, going to the proxy page on the affected object and re-saving it fixes the problem. This makes the proxy settings "stick" even though the settings do not appear to be lost. We can see in the properties file on the file system that the proxy settings are there. Perhaps there is a bug in how Apelib loads proxy settings when it pulls an object from the file system.
-Chris
I'm responding to myself to finalize this thread in case anyone else runs into this problem. Line 212&213 in Products/Ape/lib/apelib/zope2/security.py read (deserialize) if proxy_roles: obj._proxy_roles = proxy_roles by changing these lines to be if proxy_roles: obj._proxy_roles = tuple(proxy_roles) we no longer get the phantom disappearing proxy role issue. Evidently, the standard C-based zope security requires that the proxy role list be a tuple and not a list as Apelib creates it as. When running with Verbose Security and Apelib, Verbose Security works fine with the proxy_roles being a list. As soon as you remove Verbose Security the proxy roles are no longer being correctly put back on the objects as far as the C based security machinery goes when they are deserialized. They show correctly through the interface, but appear to be ignored by the security machinery. Finally, updating the objects through the zmi runs the manage_proxy function which takes the list of roles and turns them into a tuple. As long as that object stays in the ram cache, it will run fine. The bug is in Apelib and is masked by Verbose Security which appears to be more forgiving as to how the proxy roles list is encoded. -Chris
participants (2)
-
Chris Kratz -
Dieter Maurer