A role is a special user account that gives a user access to specific programs and the authorizations and privileges necessary for running them. All users who can assume the same role have the same role home directory, operate in the same environment, and have access to the same files. Users cannot log in directly to a role. They must log into their user account prior to assuming a role to ensure that the user's real UID is recorded for auditing. (Another restriction that supports auditing is that a user cannot assume any other role directly from a role.) To assume a role, users authenticate themselves by providing the role password. The user is then granted access to a dedicated role workspace where the user has access to trusted applications, the profile shell, and the trusted path attribute.
The Trusted Solaris environment provides one preconfigured role (root) and four recommended roles as shown in the table below. If your site plans to use these roles, you need to configure them according to the instructions in the "Create Administrative Roles" section in Trusted Solaris Installation and Configuration.
Table 1-1 Roles and Their Responsibilities
The Trusted Solaris environment is highly configurable so that you can implement a customized set of roles and rights profiles. (Note that this type of customization would be done by the primary administrator role.) If your site does reconfigure roles, make sure all users know who is performing each set of duties.
Your site may need new roles in addition to the predefined administrative roles. The main reason for creating a role is to define an explicit job responsibility that can use special commands and actions and any necessary privileges, that needs to be isolated from normal users, and that uses a shared home directory, files, and environment.
If you need to isolate commands and privileges with separate home directories and files for different users, then you should create a special rights profile instead of a role, as described in the next section.