All system objects include permissions in the form of an access control list. The access control list (ACL) specifies the roles that have access to the object and the types of actions those roles are authorized to perform on an object.
When creating an object, full access to the object is granted by default to the current role. However, if you have specified an object permissions template for a role, a list of permissions can be automatically granted for an object when that object is created. That list of permissions is derived from an ACL template that you can assign to the role. For more information about object permissions templates, see Creating roles.
When you create or modify a system object, you can specify individual system authorizations or authorization profiles. If the object is a server, you can add individual command authorizations. You can also use authorization profiles, ACL templates, and ACL policies to add multiple entries to the object's ACL.
When defining permissions for a system object, you can assign authorizations to a role called Everyone. Permissions granted to Everyone are available to all roles in BMC Server Automation. Using the Everyone role is an easy way to make a system object public. For example, if you are assigning permissions to a BLPackage and you grant BLPackage.Read to the Everyone role, any role can read this BLPackage (assuming that role also has a class-level permission to read BLPackages).
If a role is deleted from the RBAC Manager folder and that role has permissions for an object, the ACL for that object is automatically updated to remove the deleted role from the ACL list. If no other roles are granted permission to the object, remember that the RBACAdmins role always has permission to read and modify the ACL for any object in BMC Server Automation.
If you use an ACL template or ACL policy to assign permissions to an object, you have the option of either merging the permissions in the ACL template or policy with the object's current list of permissions or replacing the current list with the permissions included in the ACL template or policy. Replacing the current list is particularly useful when you promote an object from one role to another. For example, when software developers complete work on an object such as a Deploy Job, they typically promote the object to QA. The Developer role might have a permission such as DeployJob.*. When the Developer role completes work on the Deploy Job and promotes it to QA, the Developer role no longer needs the same level of permissions. From then on, it only needs DeployJob.Read. During testing of the job, the QA role only needs DeployJob.Read and DeployJob.Execute permissions. These varying permission levels can all be captured in an ACL template or policy, making it easy to reset permissions for an object when it is promoted between roles.
When you select a system object, the Permissions view lists the current permissions for that object. You encounter a similar list when using a wizard to create most types of system objects. The following procedure can be used in either context. This procedure is referenced by many other procedures that describe how to create or modify system objects.
Display a list of permissions for a system object by doing any of the following:
Minimum permission required
Select an existing system object and then select the Permissions view.
Use a wizard to create a system object and display the Permissions panel of the wizard.
Select a system object, right-click, and select Update Permissions.
Using the Configuration Object Dictionary, select a configuration object, right-click, and select Update Permissions.