During Solaris 11.1 installation, the
system administrator is prompted for a user name and password which
will be used to create an unprivileged account. For security reasons,
by default, root is a role, not a user, therefore the initial login
can't be to a root account. The first login must use the initial
unprivileged account. Later, the initial unprivileged user can acquire
privileges through either "su" or "sudo".
For enterprise class deployments, the system administrator should be
familiar with RBAC and create users with least privileges.
In contrast, I'm working in a lab environment and want to be able to
simply and quickly create new users with power like the initial user.
With Solaris 10, this was straight forward, but Solaris 11 adds a couple
Create a new user jenny in Solaris 11:
# useradd -d localhost:/export/home/jenny -m jenny
# passwd jenny
Jenny can't su to root:
jenny@app61:~$ su -
Roles can only be assumed by authorized users
Because Jenny doesn't have that role:
Give her the role:
root@app61:~# usermod -R root jenny
And then Jenny can su to root:
jenny@app61:~$ su -
Oracle Corporation SunOS 5.11 11.1 September 2012
You have new mail.
But even when jenny has the root role, she can't use sudo:
jenny@app61:~$ sudo -l
Sorry, user jenny may not run sudo on app61.
jenny@app61:~$ sudo touch /jenny
jenny is not in the sudoers file. This incident will be reported.
Oh no, she is in big trouble, now.
User jeff was created as the initial account, and he can use sudo:
jeff@app61:~$ sudo -l
User jeff may run the following commands on this host:
But jeff isn't in the sudoers file:
root@app61:~# grep jeff
So how do you make jenny as powerful as jeff with respect to sudo?
Turns out that jeff, created during the Solaris installation, is in
jeff ALL=(ALL) ALL
My coworker, Andrew, offers the following advice: "The last line of
/etc/sudoers is a directive to read "drop-in" files from the
/etc/sudoers.d directory. You can still edit /etc/sudoers. It may better
to leave svc-system-config-user alone and create another drop-in file
for local edits. If you want to edit sudoers as part of an application
install then you should create a drop-in for the application - this
makes the edits easy to undo if you remove the application. If you have
multiple drop-ins in /etc/sudoers.d they are processed in alphabetical
(sorted) order. There are restrictions on file names and permissions
for drop-ins. The permissions must be 440 (read only for owner and
group) and the file name can't have a dot or ~ in it. These are in the
very long man page."