User-defined authorizations
In addition to system-defined authorizations, AIX® RBAC allows system administrators to define their own custom authorizations in the authorization database (/etc/security/authorizations). These are known as user-defined authorizations.
A system administrator can add, modify, or delete user-defined authorizations. For example, a system administrator can allow some users to run a privileged command by creating a user-defined authorization and then associating this authorization with the command and granting the authorization to a role that is assigned to these users.
- User-defined authorizations must be defined beneath a new top-level parent. In other words, user-defined authorizations cannot be children of system-defined authorizations (aix).
- An authorization name can contain a maximum of 63 printable characters.
- An authorization's parent hierarchy can contain a maximum of eight levels.
- An authorization can have any number of immediate children, but can only have one immediate parent. Two independent authorizations cannot have the same immediate child.
Since the hierarchy does not allow an element to have multiple direct parents, you cannot create a user-defined authorization that is a parent of an existing system-defined authorization. Therefore, an attempt to create an authorization named aix.custom will fail and the creation of an authorization named custom.aix will result in a brand new authorization and does not function as the parent of the aix system-defined authorization.
The following syntax is suggested when creating user-defined authorizations to avoid conflicts between authorization names across multiple software components:
vendor_name.product_name.function.function1.function2...
- vendor_name
- Identifies the name of the vendor of the software module.
- product_name
- High-level product name of the product that is managed with RBAC.
- function, function1, function2 ...
- These strings represent the functions that are being managed with RBAC. These strings also provide a hierarchical representation of how these functions are organized.
For example, ibm.db2.manage could potentially represent the management aspects of the IBM® DB2® database suite. As mentioned previously, the vendor_name string aix is reserved for AIX use and is not allowed for user-defined authorizations.
lsauth –f –a description ALL_USR- Would it be appropriate to use an existing system-defined authorization instead of creating a new user-defined authorization?
- Does the new authorization belong beneath an existing user-defined authorization hierarchy or is it the first authorization of a new hierarchy?
- If this is a new hierarchy, what is the structure?
- What is the text description of the authorization?
- Is language translation of the authorization description required?
- Is there any reason to specify a certain authorization ID when creating the authorization? It is recommended that the mkauth command be used to generate the authorization ID.
- If language translation is required, create or add the description to a message catalog.
- Use the mkauth command to create all parent authorizations in the hierarchy if these do not already exist.
- Use the mkauth command to create the desired authorization. Specify the id attribute with the command if a specific value is required.