You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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_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 levelView
permission 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 hadView
permission, even though this was not obvious by looking atmanage_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 inmanage_access
and its backendpermission_settings
.The text was updated successfully, but these errors were encountered: