[Zope] Problems with removing Verbose Security and possibly Apelib

[Chris Kratz]

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