In the root role, the initial user has all administrative rights. As root, this user can assign administrative rights, such as a role, a rights profile, or specific privileges and authorizations to trusted users. This section describes how these users can use their assigned rights.
To perform your administrative tasks, open a terminal window and choose from the following options:
If you are using sudo, type the sudo command.
For administrators who are familiar with the sudo command, run the command with the name of an administrative command that you are assigned in the sudoers file. For more information, see the sudo (1M) and sudoers (4) man pages.
If your task requires superuser privileges, become root.
% su - Password: xxxxxxxx #
If your task is assigned to a role, assume the role that can perform that task.
In the following example, you assume an audit configuration role. This role includes the Audit Configuration rights profile. You received the role password from your administrator.
% su - audadmin Password: xxxxxxxx #
The shell in which you typed this command is now a profile shell. In this shell, you can run the auditconfig command. For more about profile shells, see Profile Shells and Rights Verification.
If your task is assigned directly to you as a user, create a profile shell in one of the following ways:
Use the pfbash command to create a shell that evaluates administrative rights.
In the following example, you have been directly assigned the Audit Configuration rights profile. The following set of commands enables you to view audit preselection values and audit policy in the pfbash profile shell:
% pfbash # auditconfig -getflags active user default audit flags = ua,ap,lo(0x45000,0x45000) configured user default audit flags = ua,ap,lo(0x45000,0x45000) # auditconfig -getpolicy configured audit policies = cnt active audit policies = cnt
Use the pfexec command to run one administrative command.
In the following example, you have been directly assigned the Audit Configuration rights profile as an authenticated rights profile. You can run a privileged command from this profile by using the pfexec command with the name of that command. For example, you can view the user's preselected audit flags:
% pfexec auditconfig -getflags Enter password: Type your user password active user default audit flags = ua,ap,lo(0x45000,0x45000) configured user default audit flags = ua,ap,lo(0x45000,0x45000)
Typically, to run another privileged command that is included in your rights, you must type pfexec again before you type the privileged command. For more information, see the pfexec (1) man page. If you are configured with password caching, you can run subsequent commands within a configurable interval without providing a password, as shown in Example 5–2.
If you are not root with the UID of 0, by default you cannot edit system files. However, if you are assigned the solaris.admin.edit/path-to-system-file authorization, you can edit system-file. For example, if you are assigned the solaris.admin.edit/etc/security/audit_warn authorization, you can edit the audit_warn file by using the pfedit command.
# pfedit /etc/security/audit_warn
For more information, see the pfedit (4) man page. This command is for use by all administrators.
Example 5-2 Caching Authentication for Ease of Role UseIn this example, the administrator configures a role to manage audit configuration, but provides ease of use by caching the user's authentication. First, the administrator creates and assigns the role.
# roleadd -K roleauth=user -P "Audit Configuration" audadmin # usermod -R +audadmin jdoe
When jdoe uses the –c option when switching to the role, a password is required before the auditconfig output is displayed:
% su - audadmin -c auditconfig option Password: xxxxxxxx auditconfig output
If authentication is not being cached, when jdoe runs the command again, a password prompt appears.
The administrator creates a file in the pam.d directory to hold an su stack that enables the caching of authentication. When authentication is cached, a password is initially required but not thereafter until a certain amount of time has passed.
# pfedit /etc/pam.d/su ## Cache authentication for switched user # auth required pam_unix_cred.so.1 auth sufficient pam_tty_tickets.so.1 auth requisite pam_authtok_get.so.1 auth required pam_dhkeys.so.1 auth required pam_unix_auth.so.1
After creating the file, the administrator checks the entries for typos, omissions, or repetitions.
The administrator must provide the entire preceding su stack. The pam_tty_tickets.so.1 module implements the cache. For more about PAM, see the pam_tty_tickets(5) and pam.conf (4) man pages and Chapter 1, Using Pluggable Authentication Modules, in Managing Kerberos and Other Authentication Services in Oracle Solaris 11.2 .
After the administrator adds the su PAM file and reboots the system, all roles including the audadmin role are prompted only once for a password when running a series of commands.
% su - audadmin -c auditconfig option Password: xxxxxxxx auditconfig output % su - audadmin -c auditconfig option auditconfig output ...Example 5-3 Assuming the root Role
In the following example, the initial user assumes the root role and lists the privileges in the role's shell.
% roles
root
% su - root
Password: xxxxxxxx
# Prompt changes to root prompt
# ppriv $$
1200: pfksh
flags = <none>
E: all
I: basic
P: all
L: all
For information about privileges, see Process Rights Management and the ppriv (1) man page.
Example 5-4 Assuming an ARMOR RoleIn this example, the user assumes an ARMOR role that the administrator assigned.
In a terminal window, the user determines which roles are assigned.
% roles fsadm sysop
The user then assumes the fsadm role and supplies the user's password.
% su - fsadm Password: xxxxxxxx #
The su - rolename command changes the terminal's shell to a profile shell. The user is now the fsadm role in this terminal window.
To determine which commands can be run in this role, the user follows the instructions in Listing Rights Profiles.