We here in Solaris land have expended a lot of energy in the past explaining pfexec. In the simplest case it was described as an alias for sudo (and when I first come to Solaris, I'm somewhat embarrassed to admit I did just that, created an alias for sudo to pfexec). But having an alternative to sudo was one of those things that made Solaris "different". When OpenSolaris was first released we tracked unsuccessful searches against our package repository - and sudo was as the top of that list.

As part of the modernization effort for Solaris, sudo eventually found its way into OpenSolaris (beginning with the 2008.11 release). However, by that time I was pretty comfortable with pfexec and never looked back - until now that is.

A big change in the Solaris 11 Express release is that pfexec has been rendered relatively toothless out of the box. The "Primary Administrator" profile is no longer assigned to the user created during installation. If you've upgraded from an earlier release of OpenSolaris, you are unaffected by this change. However, on a fresh installation of Solaris 11 Express, commands that used to work will no longer. For example:

bleonard@solaris:~$ pfexec zfs create rpool/myfs
cannot create 'rpool/myfs': permission denied

However, sudo now works just fine:

bleonard@solaris:~$ sudo zfs create rpool/myfs

One big difference you'll notice is that sudo requires a password - and this your password, not the root password (which I'll address in a moment). The lack of a password prompt was the whole reason for the "Primary Administrator" role being dropped in the first place - although sudo can be configured to behave the same.

If you've upgraded to Solaris 11 Express, you have the opposite problem, pfexec still works as you're accustomed, however, sudo reports you to the sudo police.

bleonard@solaris:~$ sudo zfs create rpool/myfs

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

bleonard is not in the sudoers file.  This incident will be reported. 

The report actually shows up in the /var/adm/messages file:

Dec  2 11:21:57 solaris sudo: [ID 702911 auth.alert] bleonard : user NOT in sudoers ; TTY=pts/2 ; PWD=/export/home/bleonard ; USER=root ; COMMAND=/usr/sbin/zfs create rpool/myfs

I'll address setting up sudo at the end of this entry.

The root Password

In the continued simplification of the Solaris 11 Express installer, it now only asks for one password, which is used as the password for both the root account and the initial user account:

However, the root password is immediately expired, as you'll see if you try to switch to root:

bleonard@solaris:~$ su
su: Password for user 'root' has expired
New Password: 

As you no longer have Primary Administrator privileges, GUI tools requiring administrator privileges will now also prompt you for the root password. For example, if you try to start the Package Manger GUI, you'll first be presented with:

There is one little glitch to be aware of - if you attempt to run a GUI that prompts for the root password, and the root password is expired, the GUI just exits. No warning or prompt for a new password is provided. This issue is being addressed: Gksu does not report expired password. So just make sure you attempt an su from the command, and set a new root password, before trying to use the GUI tools that require the root password.

The root Role

If you look at the installer screen capture above, you'll see that the initial user is assigned administrative privileges. Although this is not in the form of the "Primary Administrator" profile, the user created at installation time does have the root role assigned to them.

bleonard@solaris:~$ roles

Some people mistakingly think that having the root role allows them to use pfexec. pfexec stands for Profile Execute, and executes commands against your assigned profiles - not your assigned roles. The root role simply allows you to su to the root user account.

The etc/sudoers file

Now to the reason why sudo works on a fresh install of Solaris 11 Express, but not on a version upgraded from OpenSolaris.  When a command is prefixed with pfexec, it first checks to see if the user executing the command has a profile which allows the execution of that command. Very similarly, when a command is prefixed with sudo, the /etc/sudoers files is first consulted to see the user is allowed to execute that command.

The /etc/sudoers file is well documented and you can defined very fine grained rules as to what a particular user is allowed to do. In the case of the user created during installation, the user is allowed to do everything (just as if they were root). Here's what the entry for my user, bleonard, looks like:

bleonard ALL=(ALL) ALL

The entry above is stating that user bleonard can run any command on any host as any user. For further details on how to fine tune a user's privileges, see the sudoers man page.

So, to configure an instance of Solaris 11 Express upgraded from OpenSolaris to operate like a freshly installed instance, you need to add a line like the above to the /etc/sudoers file. Note that the file is read-only and should be edited using the visudo editor - I hope you like vi :-).

One last note, if you want sudo to behave like pfexec (sans password), make the following tweak to your entry:


Finally, if you're on a fresh install of Solaris 11 Express and want to continue using pfexec, you can add the "Primary Administrator" profile as follows:

bleonard@solaris:~$ sudo usermod -P "Primary Administrator" bleonard
UX: usermod: bleonard is currently logged in, some changes may not take effect until next login.

Now creating that file system works just fine:

bleonard@solaris:~$ pfexec zfs create rpool/myfs

Happy sudoing or pfexecing, whichever you prefer.


Are there any plan to add support in solaris for RBAC + LDAP on a per host? similar to what sudo supports

Posted by Eli Kleinman on December 02, 2010 at 09:50 AM GMT #

configuring sudo was a mistake, you do not mix 2 administrative models such as the ones for sudo and pfexec is an architecture problem that should not exist in solaris.
if the problem was that pfexec didnt ask for a password, then pfexec should have been modified to ask for one. You can keep backwards compatibility by using one of the reserved spaces in the profiles file to add a flag to check what password to use if your own, roots or none

Posted by nacho on December 02, 2010 at 09:57 AM GMT #

nice article, thanks.

ps. typo in "the GUI just exists."

Posted by alex on December 02, 2010 at 11:05 AM GMT #

Thanks Alex, corrected.

Posted by William Leonard on December 02, 2010 at 11:14 AM GMT #

Thanks for this blog post. I've installed Solaris 11 Express and observed the expired root password, the need to run sudo and the default "broken-ness" of pfexec but hadn't got around to investigating why. Now it all makes sense!

Posted by JR on December 02, 2010 at 12:53 PM GMT #

I totally agree with nacho, sudo is a big mistake and I fail to see why it's been added by default.
I personally like the RBAC model and will stick to it.
Also, as noted Colin Seymour (, from sudo(1m):

sudo does not create audit(2) records; for a Role Based
administration solution that performs auditing of all
actions, please refer to rbac(5).

Posted by Carlos on December 15, 2010 at 01:33 PM GMT #

The actual link should be something like this, sorry:

Posted by Carlos on December 15, 2010 at 01:37 PM GMT #


Certainly RBAC profile entries can be stored in LDAP, and individual hosts can be configured (via nsswitch.conf) to look for profiles in LDAP, files, or a combination of the two.

Does sudo have a feature that does something beyond that?


Posted by W Brian Leonard on January 04, 2011 at 09:00 AM GMT #

Hi Brian,

With RBAC the profile can be stored in LDAP, and the host could then point to LDAP with nsswitch.conf, but once the host is pointed to LDAP all profiles will apply this host. For example I create a LDAP profile allowing the user to restart cron, this profile will then be used/allowed to all LDAP client's, I have not seen how I could enforce a profile to only some host's.

With sudo you could store the profile in ldap, but the profile also has a host/(allowed) filed (example below), which will grant the profile to only the host's in sudoHost on the profile.
dn: cn=apps,ou=sudoers,,dc=domain,dc=com
sudoUser: usera
sudoUser: userb
sudoHost: hosta
sudoHost: hostb
sudoHost: hostc
sudoCommand: /etc/init.d/cron\*
objectClass: top
objectClass: sudoRole
cn: apps

I think this is the only missing area in RBAC today.

Posted by Eli Kleinman on January 04, 2011 at 09:56 AM GMT #

Post a Comment:
  • HTML Syntax: NOT allowed

The Observatory is a blog for users of Oracle Solaris. Tune in here for tips, tricks and more as we explore the Solaris operating system from Oracle.


« June 2016