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.

            http://www.roble.com/docs/sol_root_shell.html