Changing root's shell

[Fred Martin_1]

When I installed HP-UX 10.20, the root user login shell was (is) /sbin/sh.

I'd prefer root have ksh, so I changed it to /usr/bin/ksh ... but I got errors, and I forget them now but in effect the complaint was that the login shell was not in /sbin.

Is it a requirement for the root login shell to be in /sbin? There is no ksh in there.

So - do I just copy ksh into /sbin from /usr/bin?

Also am wondering if ksh is not there already for some good reason.

Thanks,
Fred

[Andreas Voss · Accepted solution]

Hi,

/sbin/sh is the posix shell which has many features of the korn shell.
When taking /usr/bin/ksh as root shell this is risky because the /usr filesystem is not mounted ie. at single user mode.
Yes, you can copy /usr/bin/ksh to /sbin/ksh.
Have you trouble with command history ?
If so you have to set some varaibles in /etc/profile or $HOME/profile to make it work:
VISUAL=vi; export VISUAL
HISTFILE=$HOME/.sh_history; export HISTFILE

(/sbin/sh has also the feature of command history like ksh)

Regards

[Alex Glennie]

man passwd: The login shell for the root user (uid 0) must be /sbin/sh. Other
shells such as sh, ksh, and csh are all located under the /usr
directory which may not be mounted during earlier stages of the bootup
process. Changing the login shell of the root user to a value other
than /sbin/sh may result in a non-functional system.
================
The root account must use /sbin/sh, and may not be changed to any
of the shells in /bin. There are a couple of reasons for this,
all of which involve /usr not being mounted in single user mode.
When the system boots, one of the first things it must do is exec
a root shell at single user mode to run fsck and the various rc
scripts. At this time, the only file systems that are mounted are
/ and /stand. /bin is really a symbolic link to /usr/bin, which is
not mounted, so the shells there are not available until /usr has
been fsck'd and mounted, so we have no way to exec one of them. In
addition, the files under /usr/bin are dynamically linked, meaning
the shared libraries under /usr and the dynamic linker /usr/lib/dld.sl
must be available to load them (/lib is also a symbolic link to/usr/lib).
The executables in /sbin are statically linked and do not require the
shared libraries or the dynamic linker.
The shell under /sbin/sh is not the old Bourne shell - it is a statically
linked version of the posix shell, which should have most, if not all,of
the functionality of the Korn shell.

HOWEVER => I heard someone tried to subvert the system sucessfully using the following :.
He set up a link from /usr/bin/ksh to /sbin/sh that is in effect
during single user mode. Then when /usr gets mounted the real
/usr/bin/ksh covers the link. So the system boots to multiuser
with /sbin/sh and then root uses /usr/bin/ksh.

STRICTLY UNSUPPORTED though !

[Fred Martin_1]

Thank you both, this is exactly what I needed to know. It is in fact the history which first annoyed me about sh.

Rather than do anything unusual as regards ksh, I set up the history per message above, so I'm satisfied for now.

If I find sh to have other shortcomings in the future I'll consider copying ksh to /sbin, but for now I'll leave it.

Thanks again,
Fred

[Cheryl Griffin]

STRICTLY UNSUPPORTED

'Tis very true!

[Carlos Fernandez Riera]

I will never do this.

Not just absolute unsuporported but the begining of problems.

Some process need /sbin/sh strictly to run.

There is a workaround, modify your /.profile
adding:
EDITOR=vi
export EDITOR
ksh
exit


This workaround let /sbin/sh for not looged in process, and let you to automoticaly start a ksh when you loggin as root.

[Dragan Krnic]

I wouldn't be so categorical Carlos.

The problem with shells other than /sbin/sh is that they are not available to root until after the /usr ist mounted if /usr is a separate volume, which it has absolutely no reason to be.

I usually allow for only 3 volumes in the vg00: boot, swap and root. Therefore I use /usr/bin/ksh for root and didn't have a single problem on account of that.

The real problem is: Why should anyone keep /usr separate from /? The standard way of partitioning into /, /stand, /usr, /opt, /tmp, /var and /home is inviting the trouble which it is supposed to eliminate, namely that in a unified volume a runaway process fills up the volume and cause a stall. By balkanizing the root volume group into so many separate volumes you are actually increasing the probability that any one of them will get full much sooner than if you kept them all coalesced in one huge volume.

[James R. Ferguson]

Hi:

Dragan makes some very good points. I suppose, too, if there weren't differences in opinion or differences in "first assumptions" there wouldn't be so many languages and so many operating systems nor even "open" ones where individual contributions are welcomed; nee solicited.

A great article on "Why Root's Default Shell Should Be The Poxix Shell" can be found at the link below. Agree, or disagree as you wish, but based on some "first assumptions" it does point out some pitfalls if you fail to follow canon.

Regards!

http://education.hp.com/itrc/news/unix_art5.html

...JRF...

[Alan Riggs]

Dragan does make some interesting points. It has made me reconsider the need to split /var into a separate filesystem. I see a danger, though, in failing to separate /home, /tmp, /usr and /opt. If these filesystems are segregated, then filling up one of them might cause a disruption in processing, but it will not crash the server. Filling up a unified / (or a segregated /var) will generally put your server into an unrecoverable state. You do increase your chances of filling up a filesystem by segregating, but you also protect yourself by walling off critical files from the explosion of a non-critical directory.

[Bo Thide']

/sbin/sh is a POSIX shell but without
support for "exotic" loacles such as Swedish.
This POSIX shell is an almost true superset
of the Korn shell, so everything you expect
from ksh is there in /sbin/sh. The reason
for not allowing other shells is that
the system must be guaranteed to have a
shell which works without other partitions
being functional.

Bo

[Carlos Fernandez Riera]

Perhaps i had a bad experience ;-)

Yes, but in other UNIX O.S. and box did not boot.

The last line in James link is clear.