All: if you use any kind of sub-sites or non-site navigation roots (in your sites or add-ons you use or maintain) where any users have local manager roles in said folder, please read on.
This message documents a security edge-case and suggested practice for add-on authors providing content with a non-site folder providing INavigationRoot. If you maintain such a configuration (or software that provides it), please note that users with a local manager role in these folders may (by default) access @@user-information and @@user-preferences views/forms (plone.app.users) in the context of those non-site navigation root folders. Said local manager users may modify properties of any site user, by cannot modify the portrait, as this requires additional permission checks performed by portal_membership. If you have a need for such configuration, you typically cannot rely on permission-to-role map fixes to prevent these local managers from accessing these views (as said local managers can access ./manage_access to change any mapping). Instead, this problem should be solved by overriding these views in the specific context of your navigation root content item's interfaces. Here are steps to mitigate this problem: 1. Make sure your content class does not directly implement INavigationRoot, and your content object does not provide it -- rather, implement/provide a marker subclass of INavigationRoot defined in your add-on. 2. Create a dummy view with a bare/empty template with a message "This view is unavailable in this context as a result of software configuration." Bind @@user-information and @@user-preferences browser views to your product-specific marker subclass of INavigationRoot. Example: http://bazaar.launchpad.net/~upiq-dev/upiq/uu.qiext/revision/172 3. Ensure that these views, when traversed to in the context of your non-site navigation root, are now obtaining the dummy view from step 2. Scope and background: * This problem is fairly limited to configurations where users have a local manager role in a non-site navigation root. * The damage that can be done is limited: local managers can only modify user properties (excepting portrait); they cannot change passwords, add new users, or initiate any kind of privilege escalation; * Because of the limited scope and risk of this problem for specific add-on edge-cases, this information is provided publicly (here) to product authors (I cleared this with [email protected] first). * This affects add-ons deployed on Plone releases >= 4.0, plone.app.users>=1.0b7. The binding of these views to INavigationRoot instead of IPloneSite solved #10439, but introduces this wrinkle for add-on authors and users of sub-sites that have local manager roles. * The resolution described above works without complication because zope.interface.adapter._lookup() (used internally for view / multi-adapter lookup) has a breadth-first interface resolution order, always finding a view registered to your marker subclass of INavigationRoot before the respective stock views are found. Ping me on #plone (supton) or reply to this thread if you have any questions. Sean [email protected] | [email protected] | #plone: supton _______________________________________________ Product-Developers mailing list [email protected] https://lists.plone.org/mailman/listinfo/plone-product-developers
