Users, roles and RBAC on Solaris: why root is a role by default and how pfexec replaces sudo

What it is

Oracle Solaris implements privileged administration through Role-Based Access Control (RBAC): rights profiles collect privileges and authorizations, and are assigned either directly to a user or to a role that a user must explicitly assume. By default on Solaris 11.4, root itself is configured as a role, not as a directly loginable user — an administrator logs in as their own named user and then assumes the root role for privileged work, rather than logging in as root or su-ing to an anonymous shared account.

Why it matters

Because root is a role, every privileged action is attributable to the named user who assumed it, which is the point of the design: a better audit trail than a shared root password. sudo is not the native mechanism here — Solaris's own tools (pfexec, roles, su to a role) predate and substitute for it. Solaris 11.4 does ship sudo (package security/sudo), and on many installations it is present, with the installer's initial user granted rights in /etc/sudoers.d/; but whether it is installed and what the calling user may run varies per host, so it cannot be assumed.

How to apply

• Create a role instead of a normal login for shared administrative duties: roleadd -c "description" -P "<profile>" <rolename>, set its password with passwd <rolename>, and assign it with usermod -R +<rolename> <user> (-R <rolename> without + replaces the user's whole role list). A role cannot log in directly; roles <user> and profiles <user> list what a user has.
• Run a single privileged command without a persistent role shell: pfexec <command>. pfexec sets the profile-shell process flag and runs the command with the rights of the calling user's own assigned profiles only — not those of any role the user may assume; commands in an authenticated rights profile prompt for the user's password first.
• Check whether root is currently a role or a user on a given host before assuming the default: userattr type root prints role for a role and nothing or normal for a user. Solaris lets an administrator switch it either way with usermod -K type=role root (make it a role) or rolemod -K type=normal root (make it a directly loginable user again). Before turning root into a role, assign the role to at least one named user (usermod -R +root <user>) and test su root from that account in a second session, otherwise nobody can become root over the network.
• For unattended scripts, assign a narrowly scoped rights profile to the account the script runs as and call the privileged commands through pfexec; a role needs su and its password, which does not suit unattended use.

Pitfalls

• Assuming a Solaris 11.4 host has sudo available and configured for you; check with command -v sudo and sudo -n -l before writing automation that calls it.
• Expecting pfexec to use a role's rights: a user who has been assigned the root role but no suitable profile gets nothing extra from pfexec; they must assume the role with su root (or su <rolename>), which is a separate, audited step.