Re: [Zope-dev] [Zope Enhancement Proposal] Sanitizing local roles
I'm very interested in all kind of enhancements to local roles. The main use is, like you said, access-restricted subsites. Currently I've added what I call "local roles blocking" to a few user folders we use (CPSUserFolder, NuxUserGroups (code available on http://cvs.nuxeo.org)) *but* there are important problems which I'll detail below. I use blocking of local roles in the sense that a local role specified somewhere can either allow the role like today (it being acquired), or block completely acquision of this role for current and deeper objects. I guess blocking only at the exact level where the roles is present would be a straightforward extension and wouldn't change the code much. The spec for blocking I use is visible at http://cvs.nuxeo.org/cgi-bin/viewcvs.cgi/NuxUserGroups/doc/BLOCKING.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup , simply put it says that a role prefixed with '-' means that the role is blocked instead of being granted (and acquired). We could use a prefix of '=' to say "grant only here but don't acquire". I'm using the standard __ac_local_roles__ datastructure to retain backward compatibility, so an old user folder implementation would just see additional roles with strange prefixes and wouldn't break everything when editing them. This works very well at the simple Zope level (indeed all the user folder products we use have specialized version of allowed() and getRolesInContext()). The problems begin when we add in CMF. CMF's catalog has to manage, for every object it indexes, an additional index called 'allowedRolesAndUsers' which is used to filter catalog objects by viewability. This index stores all roles having the permission View in the role/permission map, and all the users whose local role gives them this permission. But when you mix in groups of users and blocking, there's no way to make this index a simple list of roles, the datastructure has to be quite richer (mathematically, we don't have non-decreasing function of the roles available when depth increases). This means that a KeywordIndex cannot be used, and I have to used a specialized index whose computation a bit more costly. (Finally, for specialized CPS things like its object repository, this means I have to expand local roles even more to be able to specify arbitray complex rules for who has what permission on an object (rules like "user foo has View, but if it's in group bar it doesn't, but if it's in group baz it has it nevertheless").) The visualization problem, while important, strikes me as secondary. But the question another poster asked, what does Zope 3 do about all this, is very important. It would be good to keep the same semantics. The difficult part is group+blocking. But I don't know enough about Zope 3 to answer these questions. Florent In article <[EMAIL PROTECTED]> you write: > Local roles are "acquired" from ancestors. > > While this is not bad for e.g. a "Manager" local role, > its conceptual usefulness is in great doubt for e.g. the "Owner" role. > It is very unclear why an "Owner" of a folder should automatically > be an "Owner" of all its content. > > I therefore propose to make "acquisition" of local roles > customizable. > > I see two potential variants: > > 1. objects get a boolean flag "__ac_acquire_local_roles__" > with default value "True" which allows "acquisition" > of all local roles. > > 2. objects get a dictionary "__ac_acquire_local_roles__" > mapping role names to a boolean which allows acquisition > for the respective role. > > Of course, the second variant provides more fine grained control > and will require a more complex UI. > > The change would affect the methods "allowed" and "getRolesInContext". > of "AccessControl.User.BasicUser" and would require > new methods in "AccessControl.Role.RoleManager" to > read and modify the new "__ac_acquire_local_roles__". > > > Moreover, I propose to change the local role management pages. > When setting local roles, information about "acquired" > local role definitions is very helpful. > I therefore propose to display this information on the local > role edit page. > > > I even would prefer a much more drastic change for both > local role management and permission-role-map management: > a compact look only overview mapping roles to users > and permission to roles, respectively, with links to > a page to edit the association of a single role or permission, > respectively. Something like: > > Role | acquire | locally assigned users| ancestor assigned users > - > Owner | no | dieter| admin, dieter > - > Manager | yes| dieter| admin > - > > The "Role" column is a link to a page to edit "acquire" > an
Re: [Zope-dev] [Zope Enhancement Proposal] Sanitizing local roles
Thanks for your answer, Dieter Maurer wrote: And If I can express yet an other wish: I would very much like to have a way to see what the settings for a particular User is. And where the settings for a given permissions have come from. You might be interested in GRUFs "Audit". When I tried it in my installation, it entered an infinite loop -- apparently some bug. But conceptually, it may come near to what you want. I do have such a tool myself. It is only that I think it should be provided by the core. Using my own tool I am allways afraid that I did not understand an obscure aspect of the security machinery correctly. Robert ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope Enhancement Proposal] Sanitizing local roles
robert rottermann wrote at 2004-7-22 21:35 +0200: >I would very much apreciate such an enhancment. > >so ++1 > >I would like to see where a role was assigned. To keep the management page simple, my proposal only would tell you "somewhere above". This is enough information to decide what to do locally. When you really would need to find the precise place you would need to go up until you see the definition. It would not be difficult to provide links for easy up movement. >And If I can express yet an other wish: >I would very much like to have a way to see what the settings for a >particular User is. And where the settings for a given permissions have >come from. You might be interested in GRUFs "Audit". When I tried it in my installation, it entered an infinite loop -- apparently some bug. But conceptually, it may come near to what you want. -- Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope Enhancement Proposal] Sanitizing local roles
Dieter Maurer wrote: Local roles are "acquired" from ancestors. I like all the suggestions in concept. However, I'm aware the Zope 3 guys have probably tackled this. Wouldn't be be better to back-port their solution rather than implementing a new and difference one? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope Enhancement Proposal] Sanitizing local roles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 23 Jul 2004 03:30 am, Dieter Maurer wrote: > Moreover, I propose to change the local role management pages. > When setting local roles, information about "acquired" > local role definitions is very helpful. > I therefore propose to display this information on the local > role edit page. I have implemented a "security information" page that details this and more info. I've always found the default security edit pages to be less than useful since they inherently use acquisition, but don't tell you what would be or is currently acquired. The code is attached. We mix it in with every object. A sample output is also attached. I have found it invaluable when debugging permissions problems. Would this be a useful thing to add to 2.8? Richard -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBAKsMrGisBEHG6TARAiwuAJ9n7wLGWzhDa7kGyr/5q8zwi3SV0QCfXX1f JAcHE9s71y9N/4oyNgRiRg4= =ATJ2 -END PGP SIGNATURE- ManageViewAccess.py Description: application/python Access permissions dump Valid Roles: User Defined Roles: Local Roles: At ObjectLocal Roles Defined '.join(['%s: %s'%(i[0], ', '.join(i[1])) for i in _['sequence-item']])"> Permission Usage: PermissionAssigned To &dtml-sequence-key; &dtml-perm; from &dtml-from; Permission Settings: PermissionHas Roles Assigned '.join([', '.join(d['roles']) + ' from %(from)s'%d for d in _['sequence-item']])"> Title: CGPublisher › Zope › CGPublisher › publishers › 1 (Jane's Books) › products › 2 (Jane's test book 2) › details Jane's Books Works About Security Messages People Products Orders Work Templates Web Space Product Information · Availability · Subject · Book Information · Cover Images Access permissions dump Valid Roles: Actioner, Anonymous, Authenticated, Contributor, Creator, Manager, Owner, Publisher, System RPC, Visitor User Defined Roles: Local Roles: At ObjectLocal Roles Defined details 2 products admin: Owner 1 2: Publisher publishers admin: Owner CGPublisher admin: Owner Permission Usage: PermissionAssigned To DELETE Delete objects from webdav.Resource.Resource HEAD View from webdav.Resource.Resource LOCK WebDAV Lock items from webdav.Resource.Resource PROPFIND WebDAV access from webdav.Resource.Resource PROPPATCH Manage properties from webdav.Resource.Resource UNLOCK WebDAV Unlock items from webdav.Resource.Resource ac_inherited_permissions Change permissions from AccessControl.Role.RoleManager acquiredRolesAreUsedBy Change permissions from AccessControl.Role.RoleManager addStorageData Manage properties from Products.CGPublisher.storage.Storage.Storage addStorageDataForm Manage properties from Products.CGPublisher.storage.Storage.Storage asCGXML View public storage metadata from Products.CGPublisher.storage.Storage.Storage countRepetitions Access contents information from Products.CGPublisher.storage.Storage.Storage dummy_public View public storage metadata from Products.CGPublisher.storage.Storage.Storage dummy_shared View shared storage metadata from Products.CGPublisher.storage.Storage.Storage dump View private storage metadata from Products.CGPublisher.storage.Storage.Storage editPane View from Products.CGPublisher.storage.Storage.Storage editPaneHelper View from Products.CGPublisher.storage.Storage.Storage genericSchemaForm View from Products.CGPublisher.storage.Storage.Storage getAttribute Access contents information from OFS.ZDOM.Element getAttributeNode Access contents information from OFS.ZDOM.Element getAttributes Access contents information from OFS.ZDOM.Node getChildNodes Access contents information from OFS.ZDOM.Node getElementsByTagName Access contents information from OFS.ZDOM.Element getFirstChild Access contents information from OFS.ZDOM.Node getLastChild Access contents information from OFS.ZDOM.Node getNextSibling Access contents information from OFS.ZDOM.Node getNodeName Access contents information from OFS.ZDOM.Node getNodeValue Access contents information from OFS.ZDOM.Node getOntology Access contents information from Products.Ontology.UsesOntology.UsesOntology getOntologyRealm Access contents information from Products.Ontology.UsesOntology.UsesOntology getOwnerDocument Access contents information from OFS.ZDOM.Node getParentNode Access contents information from OFS.ZDOM.Node getPreviousSibling Access contents information from OFS.ZDOM.Node getSchemasForPaneSelect View from Products.CGPublisher.storage
Re: [Zope-dev] [Zope Enhancement Proposal] Sanitizing local roles
I agree with you, technically it is not in line with Dieter's proposal. But locically. Whenever I come accross one I have to deal with the other. And I never said, that we have to add all the information to one single table.. As you said, it is not really hard to write the code for a task as I propoaed. It is the fact that there is no easy way to get at this (badly needed) information that is anoying. Robert Andreas Jung wrote: --On Donnerstag, 22. Juli 2004 21:35 Uhr +0200 robert rottermann <[EMAIL PROTECTED]> wrote: I would like to see where a role was assigned. And If I can express yet an other wish: I would very much like to have a way to see what the settings for a particular User is. And where the settings for a given permissions have come from. Your problem is mainly a problem of visualization. and at least not directly related to Dieters proposal. For a project I wrote a UI where you can see for a given object in the ZODB hierarchy which permission/role settings are defined above in the tree and which subobjects override the settings. The code for doing this is not really a problem. The problem is how to put these informations in a UI. Given the nature of the problem one would really need a 3D display..maybe 4D :-) Andreas Jung zopyx.com - Software Development and Consulting Andreas Jung ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope Enhancement Proposal] Sanitizing local roles
I would very much apreciate such an enhancment. so ++1 I would like to see where a role was assigned. And If I can express yet an other wish: I would very much like to have a way to see what the settings for a particular User is. And where the settings for a given permissions have come from. Robert Dieter Maurer wrote: Local roles are "acquired" from ancestors. While this is not bad for e.g. a "Manager" local role, its conceptual usefulness is in great doubt for e.g. the "Owner" role. It is very unclear why an "Owner" of a folder should automatically be an "Owner" of all its content. I therefore propose to make "acquisition" of local roles customizable. I see two potential variants: 1. objects get a boolean flag "__ac_acquire_local_roles__" with default value "True" which allows "acquisition" of all local roles. 2. objects get a dictionary "__ac_acquire_local_roles__" mapping role names to a boolean which allows acquisition for the respective role. Of course, the second variant provides more fine grained control and will require a more complex UI. The change would affect the methods "allowed" and "getRolesInContext". of "AccessControl.User.BasicUser" and would require new methods in "AccessControl.Role.RoleManager" to read and modify the new "__ac_acquire_local_roles__". Moreover, I propose to change the local role management pages. When setting local roles, information about "acquired" local role definitions is very helpful. I therefore propose to display this information on the local role edit page. I even would prefer a much more drastic change for both local role management and permission-role-map management: a compact look only overview mapping roles to users and permission to roles, respectively, with links to a page to edit the association of a single role or permission, respectively. Something like: Role| acquire | locally assigned users| ancestor assigned users - Owner | no | dieter| admin, dieter - Manager | yes| dieter| admin - The "Role" column is a link to a page to edit "acquire" and "locally assigned users" for the respective role. Advantages: * more natural behaviour for roles like "Owner" * access restricted sub-sites would be much easier to implement * more informative management pages Risks: * Classes deriving from "AccessControl.BasicUser" may have overridden "allowed" and "getRolesInContext". Such overridden methods would not interpret "__ac_acquire_local_roles__" until adapted. Fortunately, it is not very likely that these two methods are overridden. * Local roles get a bit more complex. However, explicit "acquisition" control is already used for the permission role mapping. Thus, users could recognize the same concept. * The 2.8/2.9 edition of the Zope Book would need to be adapted. If there is interest, I could implement the changes and provide patches against the Zope SVN version. However, I do not have write permissions to the repository. This means, someone else would need to make the actual checkins. BTW: Almost surely, I will implement the proposed change in our "private" Zope copy and use it in one of our projects. This means, I could provide "production experience" for the change in some months. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] [Zope Enhancement Proposal] Sanitizing local roles
Local roles are "acquired" from ancestors. While this is not bad for e.g. a "Manager" local role, its conceptual usefulness is in great doubt for e.g. the "Owner" role. It is very unclear why an "Owner" of a folder should automatically be an "Owner" of all its content. I therefore propose to make "acquisition" of local roles customizable. I see two potential variants: 1. objects get a boolean flag "__ac_acquire_local_roles__" with default value "True" which allows "acquisition" of all local roles. 2. objects get a dictionary "__ac_acquire_local_roles__" mapping role names to a boolean which allows acquisition for the respective role. Of course, the second variant provides more fine grained control and will require a more complex UI. The change would affect the methods "allowed" and "getRolesInContext". of "AccessControl.User.BasicUser" and would require new methods in "AccessControl.Role.RoleManager" to read and modify the new "__ac_acquire_local_roles__". Moreover, I propose to change the local role management pages. When setting local roles, information about "acquired" local role definitions is very helpful. I therefore propose to display this information on the local role edit page. I even would prefer a much more drastic change for both local role management and permission-role-map management: a compact look only overview mapping roles to users and permission to roles, respectively, with links to a page to edit the association of a single role or permission, respectively. Something like: Role| acquire | locally assigned users| ancestor assigned users - Owner | no | dieter| admin, dieter - Manager | yes| dieter| admin - The "Role" column is a link to a page to edit "acquire" and "locally assigned users" for the respective role. Advantages: * more natural behaviour for roles like "Owner" * access restricted sub-sites would be much easier to implement * more informative management pages Risks: * Classes deriving from "AccessControl.BasicUser" may have overridden "allowed" and "getRolesInContext". Such overridden methods would not interpret "__ac_acquire_local_roles__" until adapted. Fortunately, it is not very likely that these two methods are overridden. * Local roles get a bit more complex. However, explicit "acquisition" control is already used for the permission role mapping. Thus, users could recognize the same concept. * The 2.8/2.9 edition of the Zope Book would need to be adapted. If there is interest, I could implement the changes and provide patches against the Zope SVN version. However, I do not have write permissions to the repository. This means, someone else would need to make the actual checkins. BTW: Almost surely, I will implement the proposed change in our "private" Zope copy and use it in one of our projects. This means, I could provide "production experience" for the change in some months. -- Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
