Objects might have multiple permissions, but can have only one permission for each user or group. For example, one permission might specify that GroupAdmin has the Administrator role on an object. Another permission might specify that the GroupVMAdmin has the Virtual Machine Administrator role on the same object. However, the GroupVMAdmin group cannot have another permission for the same GroupVMAdmin on this object.
A child object inherits the permissions of its parent if the parent’s propagate property is set to true. A permission that is set directly on a child object overrides the permission in the parent object. See Example 2: Child Permissions Overriding Parent Permissions.
If multiple group roles are defined on the same object, and a user belongs to two or more of those groups, two situations are possible:
- No permission for the user is defined directly on the object. In that case, the user gets the union of the permissions that the groups have on the object.
- A permission for the user is defined directly on the object. In that case, the permissions for the user take precedence over all group permissions.
Example 1: Permission Inheritance from Multiple Groups
This example illustrates how an object can inherit multiple permissions from groups that are granted permission on a parent object.
In this example, two permissions are assigned on the same object for two different groups.
- PowerOnVMRole can power on virtual machines.
- SnapShotRole can take snapshots of virtual machines.
- PowerOnVMGroup is granted the PowerOnVMRole on VM Folder, with the permission set to propagate to child objects.
- SnapShotGroup is granted the SnapShotRole on VM Folder, with the permission set to propagate to child objects.
- User 1 is not assigned specific privileges.
User 1, who belongs to both the PowerOnVMGroup and the SnapShotGroup, logs in. User 1 can both power on and take snapshots of both VM A and VM B.
Example 2: Child Permissions Overriding Parent Permissions
This example illustrates how permissions that are assigned on a child object can override permissions that are assigned on a parent object. You can use this overriding behavior to restrict user access to particular areas of the inventory.
In this example, permissions are defined on two different objects for two different groups.
- PowerOnVMRole can power on virtual machines.
- SnapShotRole can take snapshots of virtual machines.
- PowerOnVMGroup is granted the PowerOnVMRole on VM Folder, with the permission set to propagate to child objects.
- SnapShotGroup is granted the SnapShotRole on VM B.
User 1, who belongs to both the PowerOnVMGroup and the SnapShotGroup, logs in. Because the SnapShotRole is assigned at a lower point in the hierarchy than the PowerOnVMRole, it overrides PowerOnVMRole on VM B. User 1 can power on VM A, but not take snapshots. User 1 can take snapshots of VM B, but not power it on.
Example 3: User Role Overriding Group Role
This example illustrates how the role assigned directly to an individual user overrides the privileges associated with a role assigned to a group.
In this example, permissions are defined on the same object. One permission associates a group with a role, the other permission associates an individual user with a role. The user is a member of the group.
- PowerOnVMRole can power on virtual machines.
- PowerOnVMGroup is granted the PowerOnVMRole on VM Folder.
- User 1 is granted the NoAccess role on VM Folder.
User 1, who belongs to PowerOnVMGroup, logs in. The NoAccess role granted to User 1 on VM Folder overrides the role assigned to the group. User 1 has no access to VM Folder or VMs A and B. VMs A and B are not visible in the hierarchy to User 1.