Several approaches to consider, not all of them necessarily exclusive

• module mechanism could swap the context for the entire process such that only read-only HierarchyManager are available
• InstallContext.getHierarchyManager and .get*Node() should provide read-only HMs and nodes
• MgnlGroup and associate classes could use the current context (they currently use, in part the system context, see notes below)
• the various addRole*, addGroup, addPermission tasks could also work around this (see attached patch for a draft/idea)

The classes of i.m.cms.security use a mixture of system and current context. They currently use this for 2 reasons: 1) bypass security; it's probably "ok" for reading, but not such a good idea for write method. In cases where this is needed, we now have the doInSystemContext approach which could help. 2) checking for "duplicates": when adding roles to groups or users, we do {{ String newName = Path.getUniqueLabel(sysHM, node.getHandle(), "0");}} to name the property into which the added group or role's uuid is saved and avoid confict. One possibility for this would be to simply use the uuid as the property name as well (would definitely avoid conflicts).