Legacy RBAC mode and enhanced RBAC mode comparison
Existing and new interfaces have been modified to check the system configuration and run the new code or follow the old behavior.
In legacy RBAC mode, only authorizations that are checked within the code of the command itself are enforced. The Kernel Security Tables (KST) do not have any affect on command execution or authorization checks. Determination of whether a user has an authorization follows the legacy RBAC mode behavior of retrieving all the user's authorizations and checking for a match. New features such as the swrole command and the default_roles and auth_mode attributes are not available in legacy RBAC mode. However, the new privileges, authorizations, and management commands for authorizations are supported in legacy RBAC mode.
The following table lists some of the differences between the legacy and enhanced RBAC modes.
| Feature | Legacy RBAC | Enhanced RBAC |
|---|---|---|
| Role activation | All of a user's roles are always active | By default, roles are not active until assumed explicitly via the swrole command |
| default_roles attribute | Not available | Supported |
| swrole command | Not available | Supported |
| Role management commands | Supported | Supported |
| Authorization management commands | Supported | Supported |
| Authorization hierarchy | Each authorization is independent. No hierarchy functionality. | Supports concept of authorization hierarchy where authorizations can be parents of other authorizations |
| Authorization checks | Only enforced if command itself checks for authorization | Enforced through Privileged Command Database and/or by the command itself |
| Granular Privileges | Supported | Supported |
| pvi command | Not available | Supported |
| Kernel Security Tables | Not available | Supported |
| RBAC Database Location | Local files | Local files or LDAP |