Velko Ivanov wrote:
The problem is easy to reproduce in a few simple steps - assuming clean
installation from the .tgz release, here is what I do:
1. create an instance (of course), zope.Manager granted principal is
crated by the mkzopeinstance script.
2. uncomment the sample zope.Member principal 'frodo' in principals.zcml
and run zope
-- using the browser from now on:
3. login with the zope.Manager principal use the grant tool to grant
zope.Manager role at the top of the site to the 'frodo' principal
4. go to manage site -> site management and add a database adapter,
gadfly will do, dbi is something in the form of dbi://dbname;dir=/tmp,
or any other dir as apropriate
5. login as frodo and go to /++etc++site/tools/yourdbaname
6. select the test page and just click on 'execute'
8. if you try (5),(6) with the zope.Manager principal, you will see the
database adapter working as expected (producing an error in this example
actually, but not 'unauthorized' exception)
Ugh. The problem seems is that the UI grant tool work only for locatable
objects like folders, pages and so on. For example if you go to /@@grant.html
and grant some role/permission for a principal a local security map will be
stored in the root folder annotations. Then if you access some folder at
/aFolder zope.app.securitypolicy.zopepolicy.ZopeSecurityPolicy does the following:
1. check for security map at /aFolder
2. get the aFolder's parent (the root folder in our case) through the
3. check for security map at /
4. check global security map defined through configuration
Then global security declarations will be overridden by local security
If object doesn't have a '__parent__' attribute and any associated security map
the security check will be based only on global security map.
Maybe we need always check security map at the root folder?
Dmitry Vasiliev (dima at hlabs.spb.ru)
Zope3-dev mailing list