A frequently asked question (FAQ) to Sun Solaris forums (Usenet groups, mailing lists, etc) is how to fix a Solaris system after modifying root's shell with a bogus entry. The question has been asked so often that it is answered in Casper Dik's Solaris FAQ list, "I changed root's shell, forgotten root's password, and I can't login.". Invariably, the question leads to a long and heated discussion about the merits of not changing root's shell. In his web-page, Solaris Root Shell Mini-FAQ, Roger Marquis correctly refutes some, but not all of the technical reasons often cited for not changing root shell from the statically linked default, /sbin/sh. While I agree that incorrect and outdated information is not useful in warning system administrators from changing root's shell, I think his page does not emphasize enough the risk of not being able to login as root if one of the dependent shared libraries is unavailable. He fails to mention that some sys admin's specifically mount /usr from a separate filesystem to overcome a small root disk or to gain some limited increase in security by mounting read-only. Worse, he includes much of his own personal opinions about good sys admin practice of which FAQ's should contain little or at least be properly labeled. He fails to acknowledge the widespread misuse of the root account, often referred to as 'root shell disease.' In this page I hope to articulate my reasoning for discouraging the changing of root's shell.
Often I hear or read people's preference for running as root with some more feature-rich than Bourne shell (sh), such as Korn (ksh), GNU Bourne Again (bash), Tenex C (tcsh), or Z (zsh). My retort is usually something like this blurb:
If you're spending so much time running interactively as root that you find statically linked Bourne Shell limiting, then you're probably spending too much time as root and spending too little time as your non-privileged user scripting common tasks so they can be reused, documented, and possibly invoked via the free software package, sudo.
In the times when you absolutely must be running interactively as root for extended periods and you feel confident that your customer isn't going to fire you when you inevitably screw up (and everyone does), what's wrong with executing the following command:
$ su - root -c "/path/to/your/favorite/dynamically/linked/shell"
which can easily be invoked by your non-privileged user via an alias, a shell script wrapper, or sudo?
My argument assumes that system administrators spend most of their time running interactively as some non-privileged user and only run as root for essential tasks. Unfortunately, a new generation system administrators particularly from the Microsoft Windows and to a certain degree, the free PC UNIX worlds spend 100% of their time running interactively as the system privileged user (one system; one user, the system privileged user.) This belies the fact that most software was not written to be executed by privileged users. It also runs counter to the premise that the more time you spend running interactively as privileged user, the more opportunity for you to make serious mistakes which can cause down-time and maybe your job. In the secure programming community there is a mantra, "run with the least privilege, in the least amount code, for the least amount of time." If you consider the shell as just another programmer's interface, then you'd be wise to limit your time spent there as root.
In a multiple system administrator environment, how does one decide which of the 5 or more popular shells, should be the default one?
Of course, Solaris is UNIX and under UNIX almost everything is possible. If you're a sophisticated, experienced UNIX admin and you want to change your root shell, then you know better than anyone what is acceptable system administration practice at your site and you certainly don't need anyone's permission. But then you also shouldn't need help changing your root shell, fixing your system if its broken, or understanding the ramifications.
$Id: root-shell.html,v 1.10 2003/11/18 07:34:00 groenvel Exp $