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 changed. 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 password file. 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 often. 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 correct. 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.