This chapter describes user permissions.
All provisioning system permissions are assigned to user groups. If you want a user to have a particular set of permissions, assign the user to a user group or a set of user groups that can provide the permissions that you want the user to have. There are two types of permissions in the provisioning system: configurable and non-configurable. Configurable permissions can be categorized by two groups: system-wide or folder-specific.
You can set system-wide permissions on the user group's Details page or by using the udb.g.mod command.
For ideas on how you might set up user permissions based on user groups, see Planning User Groups and User Accounts. For instructions on how to implement permissions with your user groups, see How to Create User Groups.
The following list includes all system-wide, user group permissions.
Host administration. Listed in the browser interface as Hosts.
You must have host administration permissions if you want to create, edit, or delete hosts, host sets, host searches, or host types.
User and user group administration. Listed as admin: users & groups.
You must have permissions on users and user groups to create, edit, or delete users or user groups.
Notification rules.
You must have notification rules permissions to set up email notification for system events.
Comparisons.
You must have comparison permissions to create, edit, delete, or run comparisons. When comparison permissions are granted, the host set to run comparisons on must also be set.
System-wide Permission Characteristics
All users are given read permissions on all provisioning system objects by default.
Users are assigned privileges based on the groups they belong to. You can add permissions to a group if you have user and group administration permissions.
User groups that have write permissions for a particular object type have write permissions on all objects of that type.
For example, if a user is assigned to a group that has write permissions for host administration, that user can make changes to all hosts, host sets, host searches, and host types.
Users in the admin user group have read, write, and execute permissions on all objects by default.
Permissions for the admin group cannot be removed or modified.
You can set folder-specific permissions on the folder's Details page or by using the fdb.f.mp command. For more information about folders, see Introduction to Folders.
For instructions on how to implement folder-specific permissions, see How to Modify the Folder Permissions of a User Group.
The following list includes all folder-specific permissions.
Run Component Procedures Permission
This permission is granted implicitly when a user is granted Create, Edit, Delete permission.
Check In Current and Configure
Assigns permissions to check in a newer version of a component and to manipulate component variable settings.
Assigns the permissions to run plans on a defined host set.
Folder-specific Permission Characteristics
Objects impacted by folder-specific permissions include folders, plans, and components.
Folders have owners called owner user groups.
Owner user groups can perform strictly administrative tasks on a folder. For example, owner user groups can change permissions on a folder, including the owner user group permission. Owner user groups do not implicitly have other folder permissions.
Folder permissions can be set by a member of the owner user group of the folder.
All users have read permissions on all folders, plans, and components by default.
Every folder has a set of permissions that are assigned to the user groups. Actions that can be taken on a folder or object contained within the folder are determined by the permissions set on that folder.
When you assign Create, Edit, Delete permission to a user group, members of the user group are able to perform several tasks in the folder. Assigning Create, Edit, Delete permission to a user group automatically assigns Run Component Procedures and Check In Current and Configure permission to the user group.
Create new subfolders
Subfolders inherit the permissions of the parent folder when the subfolders are created. These permissions can only be modified by the owner user group.
Create new plans, components, and folders within the current folder
Check in new versions of plans and components
Rename subfolders
Change a folder's description
Move plans, components, and folders
To move an object, you must have write permission on the parent folder and the destination folder.
Delete plans and components
Delete folders
To delete a folder, you must have write permission on the parent folder and all subfolders.
Perform all tasks allowed by Run Component Procedures and Check In Current permissions.
You need to be particularly careful about assigning Create, Edit, Deletepermission to a user group when that user group also has Allow on Host Set permission. Users in this type of user group will have free reign over a particular host set since they will be able to write plans and execute them as they choose.
When you assign Run Component Procedures permissions to a user group, members of the user group are able to execute plans that are generated by directly running component procedures. These plans are created from component procedures and are stored in the /system/autogen folder. Run Component Procedures permissions is assigned from the folder that contains the component that generated the plans.
Run Component Procedures permission is granted automatically when a user is granted Create, Edit, Delete permission. However, you might want to exclusively grant the Run Component Procedures permissions when you want a user group to have permission to run only component procedures or plans that have already been written. This permission is particularly useful if you have one user writing plans and another user running them, and you don't want the users to perform tasks outside of their functional expertise.
Run Component Procedures permission is an extension of the Allow on Host Set permission. You can only run component procedures on the host set defined by the Allow on Host Set permission.
If component procedures contain variable sets that require user input, the user who runs the component procedure will need to belong to a user group that has Check In Current and Configure permission.
There are a few scenarios where you need to be particularly careful about assigning Run Component Procedures permission to user groups.
Large user groups in folders that contain sensitive materials (for example, system services that perform potentially destructive operations are usually granted execution on all host sets)
User groups that have permissions to run plans on large host sets
When you assign Check In Current and Configure permission to a user group, members of the user group are able to check in new versions of components and create, edit or delete component variable settings.
Check In Current and Configure permission is granted automatically when a user is granted Create, Edit, Delete permission. However, you might want to exclusively grant the Check In Current and Configure permission when you want someone to be able to perform deployments but not be able to manipulate the components in a folder.
Operations that are not allowed with Check In Current and Configure permission include the following.
Show and hide objects
Change an object's category
Create, edit, delete, or move objects
When you assign Allow on Host Set permission to a user group, members of the user group are able to execute custom plans and generated plans on a single host set. This permission also allows users to create a dependency on a component that is installed on a particular host.
For a user to be able to run component procedures, the user must belong to a user group with Allow on Host Set and Run Component Procedures permissions assigned. The host set defined by the Allow on Host Set permission establishes which hosts the component procedure can be run on.
The CLI and browser interface have a different naming scheme for user permissions. The following table lists the browser interface permission names and their CLI counterparts.
Table 3–1 HTML and CLI permission names
HTML User Interface Names |
Command-Line Interface Names |
---|---|
Create, Edit, Delete |
write |
Run Component Procedures |
autorun |
Check In Current and Configure |
checkin-current |
Allow on Host Set |
execute |
The provisioning system also has non-configurable permissions assigned to users and user groups.
Members of the admin user group have all permissions on all objects in the provisioning system and can modify any object regardless of ownership.
See admin User Group.
Members of the admin user group are also the only users who can import plug-ins and create component types and system services.
Owners of processes have permission to stop the processes that they started. For example, if you start a comparison, you can stop the comparison.
Users cannot stop a process that they did not initiate unless they belong to the admin user group.
All registered users have read permissions on all objects.