It is possible to change the ACL inheritance model used for selected ACLs. Changing inheritance is useful in organizations where only explicitly specified groups should have access to configuration management subprojects, even if other groups have permission to access the parent project.
The use case for breaking ACL inheritance is when only explicitly specified groups should have access to subprojects. Consider the following example:
As illustrated in the diagram, permission is denied everyone for the Global ACL. Group A, Group B, and Group C are the only groups granted permission to the Project ACL. Group D is the only group granted permission to the Subproject ACL.
By default, ACL Inheritance is enabled, which results in Subproject ACL being accessible by Group A, Group B, Group C, and Group D. All of those groups have access to Subproject ACL because users who are granted permission to Project ACL also have permission to Subproject ACL.
However, the use case is that only explicitly specified groups
have access to a subproject. In this example, one group named Group
D should be the only group able to access Subproject ACL. That use
case is true when ACL Inheritance is changed (see
The following are key considerations when breaking ACL Inheritance:
There may be a large number of permissions and groups in an ACL. Changing ACL inheritance impacts all of those permissions and groups.
Some organizations may have groups that need access to all configuration management projects and subprojects. Breaking ACL inheritance requires explicitly granting permission to those groups for each project and subproject they need to access.
When ACL inheritance is broken for an ACL (the
To determine
the inheritance status of an ACL, select the ACL. Then select the
To change ACL inheritance in the Administration
Client, first select the ACL. Then select
Changing ACL inheritance has an impact on development path inheritance. Consider the following example:
This example is an extension of the one in
By default, ACL inheritance and devpath inheritance is enabled, which results in Variant Subproject ACL still being accessible by Group A, Group B, Group C, Group D and Group X. All of those groups have access to Subproject ACL because users who are granted permission to Project ACL also have permission to Variant Subproject ACL, even when no groups are granted permission to Variant Subproject ACL.
However, the use case is that only explicitly specified groups have access to a subproject. In this example, only Group D should have access to Subproject ACL. That use case is true when ACL Inheritance is broken and devpath inheritance is still enabled.