Solaris Root Shell Mini-FAQ
Some sysadmins still recommend against changing the root shell on
Solaris systems. Ask why and you may be told that root needs a
statically linked shell which is not dependent on the dynamic
libraries under /usr/lib. This was true in the past but is not
necessarily the case today. Solaris, when properly configured,
is like any other version of Unix and can support whatever shell
you define, for root or any other account.
The reason root's default shell (/sbin/sh) is statically linked is
historical. Back when 127MB was considered a large disk /usr (and
the libraries under /usr/lib) had to be mounted from a second disk
or NFS server. When a system boots into single-user mode it does
not mount partitions other than /, breaking any dynamically linked
program. The solution to this is simple: don't partition /usr
and avoid the resulting point of failure. Since the advent of
larger hard drives there has not been a good reason to partition
/usr. Other Unix distributions have been reliable without system
partitions or statically linked binaries for several years now.
The shell specified in /etc/passwd is root's interactive
shell and should be suited for command-line usage. As long as you
have not partitioned /usr and your root's shell is also on
the root partition you can safely use bash, tcsh, ksh or any other
shell for the root account.
This Mini-FAQ addresses the misconceptions which are often given
as reasons for not changing the Solaris root shell.
Misconception 1: The password file will get misedited and the root
account will be locked-out.
While it's always possible to mis-edit /etc/passwd using a text
editor this does not mean that the root shell should not be changed.
It does mean that the password file should be edited with "vipw"
instead of "vi /etc/passwd".
Misconception 2: SunSolve FAQs and SRDBs strongly suggest that
you not change root's shell.
Perhaps this was true several years ago but a cursory search for
[root shell] turned up a number of articles explaining how to
change the root shell safely (FAQ ID 2707, SRDB 6282, and SRDB 6307).
Misconception 3: Cron scripts will not work if the root shell is
Cron scripts are run under the Bourne shell regardless of the
root shell. This has been the case since at least SunOS 3, if
not SunOS 1.
Misconception 4: A dynamically linked root shell will be unusable
if /usr/lib becomes corrupted or moved.
This is true, however, the vast majority of Unix sysadmins will
never see this occur in their careers. More importantly, /usr is
no more likely to become corrupt than /sbin. Finally, if you
munge /usr or /usr/lib it's likely you will need more than
/sbin/sh in single-user mode to fix it since ftp, rcp, ufsrestore,
and other key utilities are all dynamically linked and/or under /usr.
Even the ls command is dynamically linked.
If you do manage to mangle /usr/lib, say from an accidental rm,
it won't matter what shell root defaults to. The only way to
fix it will be to boot from CD.
Misconception 5: The startup scripts under /etc/rc* will not work
if the root shell is changed.
This was partly true several years ago. From 2.3 onward (1994?)
all system rc scripts are executed under sh regardless of the root
shell (see /etc/rcS).
Misconception 6: Sysadmins are spending too much time as root if
they want to change the shell.
Professional systems administrators normally spend a large portion
of their time as root. It is a requirement of the job. While
it certainly is true that tasks which can be performed as a
non-root user should be this does not mean that Unix sysadmins
have no legitimate reasons for working as root nor that these
admins cannot be more productive with a modern shell.
Misconception 7: You'll need a CDROM drive on any machine where
the root shell is changed, in case you need to boot to another
This is incorrect. As long as the root shell is correctly defined,
on the root partition, and /usr/lib is on the root partition
there will be no problem booting single-user and logging-in as
root using a dynamically linked shell.
If your system has a partition for /usr or /usr/lib it would be
prudent to move it to the root partition. Depending on a server's
applications /home, /var/spool, /var/sadm, /var/tmp, /opt, and
/usr/local can be symlinked or partitioned and mounted from another
drive but /usr should not normally be separated from the root
partition. Also, quoting Solaris FAQ maintainer Casper Dik: the
"most important reason for not having a separate /usr: if anything
gets mounted, /usr will be there."
Misconception 8: Unless you have a good reason to change the root
shell it is better to leave it alone.
This is one piece of good advice, however, if there were no good
reasons changing it would not be such a common practice.
Misconception 9: It's just as easy to run another shell when you
login or su.
If that were the case this question probably would not come up so
Misconception 10: There are many reasons to not change the root
shell all you need to know is to never do it again.
Claims that anything is "all you need to know" are generally not
Resolution: Solaris 9
After several years of requests Sun addressed this in SunOS 5.9
(marketed as Solaris 9) by allowing for a fail-over login shell.
Beginning with (5.)10 Solaris will no longer have static binaries.
This will eliminate the static /sbin/sh as all shells, root and
otherwise, will be dynamic. The resulting OS will be considerably
simpler to install, patch and maintain.