SUMMARY: replacing the Bourne shell with the Korn shell

WOW! That generated an avalanche...

Replacing /sbin/sh with another program like /usr/bin/ksh is probably
not a good idea at all. In fact, EVERYONE said it was a horrible idea!
Many people pointed out that /sbin/sh is statically linked. Other
programs like /usr/bin/ksh and /usr/bin/sh aren't. (You can use the ldd
command to see this.)

If you do replace /sbin/sh with /usr/bin/ksh, you may not notice any
side effects until you reboot. I tried this on a server that I could
afford to lose just to see what would happen. After I executed "reboot",
the server went down and never came back up. Unfortunately, I'm at home
and the server is at the office, so I couldn't see what was happening at
the console. I suppose there's a slim chance that the server isn't on
the network for some other reason, but my money is on the change I made
to /sbin/sh.

After thinking about this limitation for a while it occurred to me that
a way to work around it might be to leave the files in /sbin alone, but
then mount a filesystem containing a copy of the directory (with the
"new" /sbin/sh) at /sbin once the system reached multi-user mode. Of
course, that's a pretty extreme tactic. Many people couldn't imagine why
I would want to replace the Bourne shell executables in the first place.
I shudder to think about what the reaction would be to the idea of
mounting on top of /sbin.

I got replies from people who warned me that there may be differences
between the Korn shell and the Bourne shell that could cause scripts
currently running under the Bourne shell to break if they were executed
by the Korn shell instead. I'm really not sure about this. Rosenblatt
(1993) says that the Korn shell is backwards compatible with the Bourne
shell except for the fact that the Bourne shell supports using ^ as an
alias for the pipe symbol. On our systems, it would be easy enough to
search for all occurrences of the ^ character in shell scripts to make
sure that this wasn't an issue. However, now that I think about it I
have noticed other differences between the two shells. For example, I
think variable scoping rules might be a little different within while
loops and/or case statements on Solaris. Anyone who is considering using
the Korn shell instead of the Bourne shell needs to keep this in mind.
The devil usually IS in the details.

Several people tried to tell me that if I want to use the Korn shell,
then I should just set the user's shell to /bin/ksh or put #!/bin/ksh at
the top of a script. Given that I had a brain fart and forgot what
/usr/bin/rsh is (it's remote shell, not the restricted shell!), I can
see why they might have felt the need to point out the obvious.

Perhaps it would help to explain my situation in some more detail:

1. The servers I wanted to make this change on are simply back-end
database servers. There are no end users on these systems who would be
offended by having the Bourne shell taken away from them.

2. Some were concerned that changes made to files in /sbin or /usr/bin
would be overwritten by patches. (Or worse, that we weren't patching our
systems at all.) Rest assured, we do patch our servers. And without
going into details, there are ways to apply patches without stomping on
customizations.

3. It was also pointed out that changing /sbin/sh voids support
contracts. A good point - if you have a support contract.

4. As many of you probably know, package install scripts are executed by
the Bourne shell no matter what you put on the first line of the script.
One thing I wanted to do was use the Korn shell to develop install
scripts. I was also concerned that scripts called by install scripts
would have to be written in the Bourne shell too (however, I have reason
to suspect that this is not the case). I did some testing and it turns
out that install scripts are interpreted by /sbin/sh, so if you replace
/sbin/sh with /usr/bin/ksh, your install scripts WILL be interpreted by
the Korn shell instead. But we've already discussed the problems
associated with changing /sbin/sh.

5. Another weird behavior that I encountered recently involves the way
$0 is expanded when you put #!<some shell> at the top of a setuid or
setgid script. Try this yourself and you'll see that instead of
replacing $0 with the name of the file, it's replaced with the pathname
of the shell instead! So now I have to choose: 1) don't use $0 to get
the filename in setuid or setgid scripts; 2) don't create setuid/setgid
shell scripts (and just in case someone is wondering - no, I'm not
creating setuid root shell scripts); or 3) don't put #!<shell> at the
top of the script. I reasoned that if I could guarantee that all scripts
would always be run by the Korn shell instead of the Bourne shell, then
option 3) wouldn't be a bad choice. And what better way to make such a
guarantee than to replace the Bourne shell executables with Korn shell
executables.

6. Many people had strong opinions about what shell root should have. If
you can't mount /usr, and root is using a shell in /usr/bin, then this
may be a problem. Or maybe not, depending on what techniques you can use
to recover in such a situation. For us, we've got backup servers that
can quickly be promoted; the only data we care about is in the database,
which is replicated between two servers and is backed up to tape; we can
rebuild a server in about an hour; and we can also boot from CD and
mount disk devices if we really need to access a filesystem.

John

P.S. In reference to my domain, one respondent guessed correctly - we're
running Solaris on two different platforms: AD450NX and C440GX+, neither
of which is a SPARC.


-----Original Message-----
From: Spurgeon, John P
Sent: Sunday, November 09, 2003 11:23 AM
To: 'sunmanagers@sunmanagers.org'
Subject: replacing the Bourne shell with the Korn shell


In Chapter 10 of "Learning the Korn Shell", Bill Rosenblatt talks about
replacing the Bourne shell with the Korn shell. I'm considering doing
this on a Solaris 7 system as follows:

rm /sbin/sh; cp -p /usr/bin/ksh /sbin/sh
rm /usr/bin/sh; ln /usr/bin/ksh /usr/bin/sh
rm /usr/bin/jsh; ln /usr/bin/ksh /usr/bin/jsh
rm /usr/lib/rsh; ln /usr/bin/ksh /usr/lib/rsh
rm /usr/bin/rsh; ln /usr/bin/ksh /usr/bin/rsh

However, I'm somewhat concerned about /usr/bin/rsh. I can see that
/usr/bin/sh, /usr/bin/jsh, and /usr/lib/rsh are all hard links to the
same program, but /usr/bin/rsh is different. Furthermore, /usr/bin/rsh
is a setuid root program.

Does anyone know why /usr/bin/rsh is different, why it is setuid root,
and what the consequences of replacing the file with /usr/bin/ksh are?

I'm not so concerned about /sbin/sh, because it's not setuid root;
however, it is also different from /usr/bin/sh. I'm curious to know what
the difference is between these two programs as well.

John Spurgeon
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers