When digging a bit deeper into the inner workings of Zope, I found this discrepancy which at least to me seems to be actually security relevant: The list of roles which have a specific permission set for an object is stored in the object itself, but its permission_settings() frontend (and therefore the manage_access-page) filters these down to those that are defined locally or in any of the objects obtained by the current acquisition context.
The consequence is that sometimes a role might have permission to do something, but an inspection of manage_access will not reveal that this is the case.
This situation can be reproduced by different means like removing a local role somewhere in an object above, copying an object somewhere else where a local role is not defined or importing an object in zexp format.
I tested this by giving a role named simple which was defined at top level View permission to an object further down (and only to that role and Manager). Then I removed the locally defined role at top level, but a user having only this role still had View permission, even though this was not obvious by looking at manage_access.
Btw, opening manage_access once and saving cleans such additional roles, but it can still happen too easily that such unintended permissions are set. I guess the solution must be a complete change in manage_access and its backend permission_settings.
When digging a bit deeper into the inner workings of Zope, I found this discrepancy which at least to me seems to be actually security relevant: The list of roles which have a specific permission set for an object is stored in the object itself, but its
permission_settings()frontend (and therefore themanage_access-page) filters these down to those that are defined locally or in any of the objects obtained by the current acquisition context.The consequence is that sometimes a role might have permission to do something, but an inspection of
manage_accesswill not reveal that this is the case.This situation can be reproduced by different means like removing a local role somewhere in an object above, copying an object somewhere else where a local role is not defined or importing an object in zexp format.
I tested this by giving a role named
simplewhich was defined at top levelViewpermission to an object further down (and only to that role andManager). Then I removed the locally defined role at top level, but a user having only this role still hadViewpermission, even though this was not obvious by looking atmanage_access.Btw, opening
manage_accessonce and saving cleans such additional roles, but it can still happen too easily that such unintended permissions are set. I guess the solution must be a complete change inmanage_accessand its backendpermission_settings.