My original question:
Unfortunatelly, I and my fellow administrators are forced to address -
once again - why root's shell is /sbin/sh, and the ramifications of
changing it. I've read the Sun-Manager's and comp.unix.solaris FAQs and
have tried to reason with our users to no avail.
I understand that:
- /sbin/sh is statically linked and therefore has no external
dependencies. This provides a minimal, safe environment;
- /bin/sh, /bin/csh, etc. are dynamically linked and are therefore
dependent on external libraries, usually found in /usr. These libraries
must exist, must be intact, and must be the correct version;
Our users want to change the root shell to /bin/ksh. My question is
this: Is the Korn shell a strict superset of the Bourne shell? In other
words, will the Korn shell _always_ execute a Bourne shell script
_exactly_ the same and the Bourne shell itself? Not all of the scripts
in /etc/init.d and /etc/rc* specify a shell; do any differences between
sh and ksh really matter?
_Any_ feedback you can provide on this subject is _greatly_ appreciated;
I'm sorry to resurrect this tired topic and would like to bury it once
and for all.
And the replies:
======================================================================
From: Todd Boss <boss@netcom.com>
DON'T Change the root shell. Add a user called "rook" with /bin/ksh
and a uid of 0. Then tell people to su - rook instead of "su" and
they'll have all the powers of root w/ the shell they want. And you
avoid any fallout ramifications of screwing around w/ the root shell
and dynamic linking and single user root access, etc.
======================================================================
From: Mark Baldwin <mark.baldwin@aur.alcatel.com>
It is generally considered a bad idea to change root's shell. If, for
instance, you lose the /usr file system and your root shell is ksh, you
are
SOL. If they really need to run ksh, have them log in and execute
/bin/ksh. But do not change root's default shell.
======================================================================
From: "Adams, Chad M CRL" <cadams@crl02.crrel.usace.army.mil>
Not exactly sure why, but I specifically remember being told to make
sure ROOT's shell is statically linked or you won't be able to login.
That's one thing to keep in mind. :)
======================================================================
From: "Iskander, Tim" <ISKANDER@infimed.com>
Heres what I do to aliviate this "problem", as I prefer tcsh
# cat /.profile
...
if [ "/dev/console" = `tty` ]
then
TERM=vt100
export TERM
fi
if [ -x /usr/bin/tcsh ]
then
echo "Starting tcsh..."
/usr/bin/tcsh
exit
fi
======================================================================
From: Matthew Fansher <fanshem@gcm.com>
Why would you ever let your users log in as root?!? I haven't personally
changed
the root shell on any of my machines, but I have heard many horror
stories from
people who have.
======================================================================
From: Karl Vogel <vogelke@c17mis.region2.wpafb.af.mil>
E> Our users want to change the root shell to /bin/ksh. My question is
E> this: Is the Korn shell a strict superset of the Bourne shell?
Pretty close. I'd be surprised if you could find a Bourne shell
script
that would misbehave under ksh.
E> Not all of the scripts in /etc/init.d and /etc/rc* specify a shell;
do
E> any differences between sh and ksh really matter?
Doesn't matter for rc scripts; my root shell is set to /bin/csh, and
if a user wants something different, we can easily arrange that in
root's .cshrc file:
# Root C-shell setup
#
# default search path
set path=(/usr/bin /usr/sbin /usr/ccs/bin /usr/ucb
/usr/openwin/bin)
# default man path; should roughly match search path.
setenv MANPATH
"/usr/share/man:/usr/openwin/share/man:/usr/local/man"
# things to do for an interactive shell
setenv HOST `hostname`
set prompt="ROOT at $HOST (\!)# "
if ( $?prompt ) then
set history=200
set savehist=200
set noclobber
set notify
set ignoreeof
set filec
unset autologout
set cdpath=(. .. ~)
endif
# environment variables
# default file browser and editor
setenv PAGER "less"
setenv EDITOR "/usr/bin/vi"
# customize based on who I really am
switch (${LOGNAME})
case someuser:
test -f /usr/local/bin/tcsh && exec /usr/local/bin/tcsh
breaksw
case otheruser:
test -f /bin/ksh && exec /bin/ksh
breaksw
default:
breaksw
endsw
======================================================================
From: "Dwight Peters" <dpeters@nswc.navy.mil>
I realize that this is not the input you're looking for, but I recall
reading
that one sysadmin who was beset with users wanting root access, simply
changed
the name of the root account to "clerk" and the number of people
requiring root
access diminished by a ten to one reduction. Sorry, I have nothing to
more
meaningfully address your question.
======================================================================
From: Jim Harmon <jharmon@telecnnct.com>
For anyone (and users should NEVER be root) who must use ksh over sh,
simply have them execute "ksh" after logging in.
Problem solved. :)
I use BASH in root all the time. I don't make it permanent per request
of my boss, but I've never had -ANY- difficulty running standard scripts
from the commandline, regardless of shell they're written in.
(I simply type "bash" whenever I login as root, and it's NEVER been a
problem.)
======================================================================
From: Rich Kulawiec <rsk@gsp.org>
I think that your users should just learn to type
exec /bin/ksh
whenever they su. It's quick, it's easy, and ducks all of the issues
involved in switching shells. I would further suggest that if they
find themselves typing this too often for their taste, that *maybe*
they ought to consider using "su" a little less often. ;-)
Yes, that's a non-technical answer, but I think this is mostly a
non-technical issue that has more to do with the way they're choosing
to do admin work than with the nuances of ksh vs. sh.
======================================================================
From: "Baugher, Alan" <ABaugher@OFFICEMAX.com>
I am concerned on another point. Why do your "users" have access to
root? Once root has been compromised this way, there is only one way to
ensure the box has no "suprises" or "back doors". If some users need
"root" to execute binaries, I would suggest using "sudo".
======================================================================
From: Rob Windsor <windsor@warthog.com>
First off, ksh is in theory a superset of sh, and I've found that to be
true as far as scripting is concerned. But it doesn't matter if...
I dealt with this by creating another root-equiv account, "lroot" if
it's
system-specific, or "<firstinitial><lastinitial>root" if it's going to
be
across several systems ("user-specific").
For example, one place where I worked had individual "lroot" accounts on
everyone's desktop so that they could so to that to shut the system down
or whatever (this was done on SunOS, they're using sudo for solaris).
The bennie of this is that you set lroot, tell the primary user what it
is, and forget about it until they leave or the system changes hands.
The last place where I worked, we distributed "xyroot" accounts, mine
happened to be "rwroot". This allowed us to add or remove user access
from systems w/o having to socially ACL the distribution of the root
password(s).
Either way, I would leave "root" to the standard for reasons of disaster
recovery, and supply an alternate root-equiv account.
Parting shot: gnu su(8) and BSD su(8) both support the `-m' flag where
the
environment (including shell) isn't changed, just the
EUID.
======================================================================
From: David Thorburn-Gundlach <david@bae.uga.edu>
You seem to have all of the basics covered; sorry I can't be of more
help.
I noticed an apparent inconsistency in your post -- "you and your
fellow admins" are hving to go through this because "your users" want
to change root's shell. Why on earth do they have any say? [Here
comes the BOFH in me :-] If they ever deserve access to root in the
first place, then let 'em have an eroot (for ed) or a droot (for david)
or whatever and guard the real root account jealously for just such
disastrous situations as you describe; at that point, joe
user^H^H^H^Hroot
can make his root account shell any darned thing he pleases. An even
better idea is sudo; they use their own account's shell and don't even
get a root shell (but be careful there; programs like vi can spawn
subshells and defeat the control).
My rule of thumb has always been to let someone have root if s/he
pushes hard enough and politically enough, but make sure that
*everyone* knows that this person will also have to clean up any
messes s/he makes; it comes with the territory just like putting gas
in the car and fixing the door if you ding it.
Best of luck; it sounds like you're in the middle of a political
battle, rather than a technical one...
======================================================================
From: Kris Briscoe <brisco_k@adm-srv.sat.mot.com>
Consider this../sbin/sh is statically linked...Should you change roots
shell to a dynamically linked shell; and should /usr need to be fsck'd
during reboot...Well...You would not be able to access the root shell
for adminstration...Then you must boot cdrom...and you know the rest....
I agree that ksh is a much better shell for root, but it is not
statically compiled yet...Here is what we have done....I created a
second root account....We call it 'kroot'.... I give it the same
uid,gid, and home as 'root', but I define the shell as /bin/ksh....This
has worked for me for a few years now...It does not pose any security
risks as far as I am concerned....best of luck...
PS...Sorta strange you promote linux on your mail, yet you post on a
'SUN' user's list.....hmmmmm
======================================================================
From: Stephen Harris <sweh@mpn.com>
> Our users want to change the root shell to /bin/ksh. My question is
> this: Is the Korn shell a strict superset of the Bourne shell? In other
No. It's 99.99% compatible though.
However,
1) NEVER LOG IN AS ROOT!
2) Always login as a real user
3) su - root -c /bin/ksh
will do what people want *and* let them keep their own $ENV setup.
My strong recommendation is to never touch root's shell.
======================================================================
From: bbyoung@amoco.com (Brad Young )
/sbin/sh is safe. It is statically linked, so bad things won't happen to
you if
someone messes with your LD_LIBRARY_PATH or LD_PRELOAD...
I say, if someone wants to use a different shell, let them do
'/bin/csh',
'/bin/ksh', '/usr/local/bin/bash', or '/foo/bar/baz' and run a subshell.
No
problem. But don't mess with root's shell....
======================================================================
From: "Pitcher, Glenn" <gpitcher@comstream.com>
Yes, ksh is a superset of Bourn shell. So anything you have written for
sh will work exactly the same under ksh. As for startup scripts -
everything is executed with /sbin/sh. Therefore you need to ensure that
your startup scripts are sh compliant and not ksh/csh!!
======================================================================
From: "Rodney C. Marable" <marable@firefly.net>
The items noted above are enough to NOT change the root shell. If they
want something else, make a groot account and let them use ksh there.
======================================================================
From: "Kevin P. Inscoe" <kinscoe@cbis.com>
well quite frankly because Sun says dont do that...that's why...it's
good
enough
for me...
I *hope* that helps.
======================================================================
From: foster@bial1.ucsd.edu
Just put something like:
alias su "su - root -c /bin/tcsh"
in your startup file (adjust appropriately for other shells).
Then your users will have the shell they want when they su to root.
I would offer this as the ONLY alternative, as changing root's shell
is a terrible idea. If they don't understand, tough, that's why you
are the system administrator.
======================================================================
From: Peter Gray <pdg@uow.edu.au>
I have 2 comments.
1) Administrators should NOT log in as root. They should use sudo
or something similar from their own account. This gives
you better security and logging of what they have done.
2) If you must log on as root, and you want to have ksh functionality
either run ksh as the first thing you do or simply run ksh
from the root profile. That way you get a safe shell
when the system is broken (/sbin/sh) and ksh functionality.
======================================================================
From: Rick Reineman <reineman1@raiders.llnl.gov>
I've been using csh as the root shell for years. On very rare occasions
I'll
have a problem when a system is really screwed up. The hard core types
insist
on /sbin/sh for the reasons you stated, in the real world csh (and ksh)
work
fine.
I did read something interesting that I haven't implemented yet. In
roots
.login you can evaluate the run state and start the shell of your choice
based
on that, eg: if (run state) = 2, then /bin/ksh or csh or whatever.
So at single user /sbin/sh will be the shell, at multiuser it's your
shell of
choice.
======================================================================
From: Mark Spooner <mark.spooner@Central.Sun.COM>
I wish your users had been on the floor when an HP/UX system would not
boot
because someone
had changed root's default shell. This was because /usr was not mounted
early on in the boot. Now
suppose root's shell on a Solaris system was in /usr but there was some
problem with /usr? Sticky
business this. What if you need to unmount /usr in stand-alone?
Whoops,
sorry -- can't do that
either. Besides, changing root's default shell is not necessary. You
can
bop into whatver shell you
want to if you know how. If you don't know how you don't need access to
the root account.
======================================================================
From: "Auteria Wally Winzer Jr." <wally.winzer@ChampUSA.COM>
IMOA you can use any shell you wish for root. Remember, the root's
shell is
only
envoked when you start a session. The "rc" files have either "/sbin/sh"
or
"/bin/sh" as its shell to execute the programs. I've seen many sites
where the
root shell is /bin/csh, /bin/ksh, etc. Currently I'm using
"/usr/local/bin/bash" as
the root's shell. It works perfectly fine.
======================================================================
From: Peter Bestel <peter.bestel@uniq.com.au>
Ed,
Just add a 'rootk' account. Then, when the system is up and running,
these 'users' of yours can log into a ksh root environment. You retain
the minimal, safe /sbin/sh environment for system failure / single user
times.
======================================================================
From: Janet Hoo <Janet.Hoo@Ebay.Sun.COM>
Anything that is run is korn can be run in bourne. Korn is bourne just
with
added features. The idea of changing root's shell is not a good one.
For one
thing, korn is NOT a stand alone shell, meaning if usr fails to mount
you cannot
get in. Also korn has a lot more features and in turn is not as secure
as
bourne. I also don't know why you have user's working as root. For one
thing,
it is much harder to track what they are doing, and it is almost
impossible to
stop them from running wild over your network. Root on one machine is
as good
as having root on all. If you don't believe me check out snoop. Force
you
users to work as themselves and su to root when they want to do
something - if
they must be root. Otherwise put them in group 14-administrative. Hope
this
helps.
======================================================================
From: Damon Atkins <Damon.Atkins@nabaus.com.au>
Your users should not have root access, however changing the root shell,
will not change the shell the rc*.d scripts run as. They will always run
as
/sbin/sh.
You should not change the shell from /sbin/sh for the reason you stated.
However you could change root's profile so if /usr/libxyz /usr/bin/ksh
etc
exist then execute /usr/bin/ksh.
The overway is to use cu-sudo.tar.gz or op.share
======================================================================
From: Stefan Voss <s.voss@terradata.de>
I don't like /sbin/sh as a shell for daily use, so i have added a new
user to
all machines. His name is "super", same UID and GID as root, same
password,
but tcsh as the login shell. So i can work with my favourate shell, but
if i
am in real trouble (or in single user mode), i still have /sbin/sh
working.
Better have sh than no shell.
And if tcsh refuses to execute a bourne shell script properly, i can
execute
the script like this:
sh SCRIPT_NAME
======================================================================
From: anders@hmi.de (Thomas Anders)
Why change /etc/passwd when you can have a safe environment *and*
the comfort of ksh? The main problem of safeness arises when /usr
is in a bad state, so why not test this first and invoke /usr/bin/ksh
when all is okay? You could add some lines to /etc/profile that
will
choice a): call /usr/bin/ksh if user is root, shell is /sbin/sh.
If there's something wrong with the dynamic libraries, ksh won't be
invoked and you are back in /sbin/sh. Shortcoming: two shells
running.
choice b): *exec* usr/bin/ksh if user is root, shell is /sbin/sh
and /usr is there and "in a good state". Problem: how can you be
*really sure* about /usr (it could be marked "clean" but somebody
mangled some libraries)?
======================================================================
From: Birger Wathne <birger@sdata.no>
I'd rather create a .profile that checks if the login is interactive,
and that the run-level is 3 and then exec's /bin/ksh.
Or just demand that the users run ksh manually.
After all, root should seldom be used by anyone but the admin.
======================================================================
From: Jean-Philippe.LEROY@st.com
You are perfectly right /sbin/sh is statically linked ... and /bin/*sh
are dynamically linked ...
(just run '# ldd /sbin/sh' and '# ldd /bin/*sh' you will see the
dependancies).
Root account should in my opinion always keep /sbin/sh just in case /usr
partition is down you are still about to login on the system. If you use
another shell it will not be ok (then if you want to go in ksh shell you
can easilly run '# exec ksh'). For all other users but root you can
define what they want.
======================================================================
From: "Alessandro Forghieri" <alf@orion.it>
I have a user ksh, with /bin/ksh as shell and UID 0. That is what I
commonly
use for interactive root sessions. I just have to remember to change
passwords to BOTH ksh and root which is not difficult
Would that work for you?
I believe that ksh is a strict superset of sh (but don't take my word
for it).
HOWEVER I would still be extremely wary of changing root's shell, also
because
I just know people would start writing system scripts using ksh - that
would
bomb under sh, should root's shell ever be reset.
No doubt you've already thought to all the above.
======================================================================
From: Ramindur Singh <ramindur@zuno.com>
I think you have answered your own question. /sbin/sh has no 'external
dependencies. This provides a minimal, safe environment.' says it all.
If
you use /bin/any_shell you will have to boot of an install CD should
there
be any problems with /usr, and this has happened few times to many sys
admins, whereas if you leave it to /sbin, you will have less chances of
things going wrong.
If users want to have ksh or any other shell for root, why not stick
this in
the .profile, this way, if there is a problem with /usr, it just won't
run
this shell...but you will have to type exit twice.
======================================================================
From: "Brian T. Wightman" <wightman@acm.org>
If you have ever had to upgrade libc (and made a mistake doing it),
you will understand _exactly_ why roots shell is statically linked.
If it is not, and libc is trashed, you had better find your
distribution media.
ksh does give some nicities over /sbin/sh, but if a super-user wants
to use ksh, they can just start it with {/usr,}/bin/ksh.
======================================================================
From: Ronald Loftin <reloftin@mailbox.syr.edu>
I'm confused. Why do the users care what root's shell is ? If they
need
more access than a normal user account, set them up with sudo.
======================================================================
From: "Christopher L. Barnard" <cbar44@tsg.cbot.com>
> Our users want to change the root shell to /bin/ksh. My question is
> this: Is the Korn shell a strict superset of the Bourne shell? In other
> words, will the Korn shell _always_ execute a Bourne shell script
> _exactly_ the same and the Bourne shell itself? Not all of the scripts
> in /etc/init.d and /etc/rc* specify a shell; do any differences between
> sh and ksh really matter?
Yes, you may safely do this. We have all of our production trading
servers
configured with root's shell as /bin/ksh and have no problems.
======================================================================
From: Greg Obremski <obremski@alpha.fdu.edu>
KOrn Shell bills itself as "bourne compliant"; i.e. it says it will
execute any bourne script. It supposedly is bourne with some
enhancments.
However....changing root's shell is a badbadbadbadBAD move. your USERS
want you to change it? why do they even care about root's shell? :) I'm
not even sure you can log into root with a different shell; if you can,
thats fine, but if you ever need ot boot single user....you're toast. I
would not recommend it. If you really must, make sure you have the cdrom
handy....because if you ever boot single user, i can almost bet you
you'll have ot boot from cdrom, manually mount c0t3d0s0 on the cdrom
under /mnt, and manually change root's shell back to /sbin/sh before you
can boot to single user off the hard drive. (Maybe you won't have to do
that on a normal system just booted to single user, but if you hose /usr
or anything...*shudder*
======================================================================
From: Mark Bergman <bergman@phri.nyu.edu>
=> Unfortunatelly, I and my fellow administrators are forced to address
-
=> once again - why root's shell is /sbin/sh, and the ramifications of
=> changing it. I've read the Sun-Manager's and comp.unix.solaris FAQs
and
=> have tried to reason with our users to no avail.
=>
=> I understand that:
=>
=> - /sbin/sh is statically linked and therefore has no external
=> dependencies. This provides a minimal, safe environment;
True.
=> - /bin/sh, /bin/csh, etc. are dynamically linked and are therefore
=> dependent on external libraries, usually found in /usr. These
libraries
=> must exist, must be intact, and must be the correct version;
True. Why take the chance, and find out that when /usr is corrupt
and doesn't mount, you cannot boot single user and fix the machine!?
=>
=> Our users want to change the root shell to /bin/ksh. My question is
=> this: Is the Korn shell a strict superset of the Bourne shell? In
other
=> words, will the Korn shell _always_ execute a Bourne shell script
=> _exactly_ the same and the Bourne shell itself? Not all of the
scripts
=> in /etc/init.d and /etc/rc* specify a shell; do any differences
between
=> sh and ksh really matter?
They might...Why take the chance? Put the following in root's
.profile:
if [ -x /usr/bin/csh ]
then
echo "/usr/bin/csh found..."
echo "execing it now"
exec /usr/bin/csh
fi
echo "No /usr/bin/csh found."
echo "Running under /sbin/sh now."
echo ""
echo "Is /usr mounted?"
with additional checks that the libraries exist, etc., etc. if you
want. This way, when the machine is really screwed up, you can still
log in.
=> _Any_ feedback you can provide on this subject is _greatly_
appreciated;
=> I'm sorry to resurrect this tired topic and would like to bury it
once
=> and for all.
Ah, did you check the archive before posting? You're right, it is a
tired topic, and I'm sure there are postings about it already...
======================================================================
From: Rich Pieri <rich.pieri@prescienttech.com>
EF> - /sbin/sh is statically linked and therefore has no external
EF> dependencies. This provides a minimal, safe environment;
Yep. That is the only reason you need, because if /usr is unavailable
and
/bin/sh or /sbin/sh is not your shell, you are screwed. If you can find
a
statically linked ksh you should be able to use it, but I have never
seen
one on a Unix with shared libraries.
======================================================================
From: crowner@oar.net (Fred Crowner)
The key is that /usr/sbin/sh in statically linked. If you have to work
at
a recovery level (like you can't mount /usr for some reason) the other
shells won't work. One of my staff members did this a few years ago
(solaris 5.3). He changed root to use /usr/local/bin/tcsh on his
workstation. A few months later he had to boot from cdrom and change
the
/etc/passwd entry back to /usr/sbin/sh for root so he could get into the
system for maintenance work. He couldn't get it up to single user mode
because it didn't mount /usr/local and he couldn't mount
/usr/local/because
he didn't have a shell.
If people want their own environments you can take a look at a package I
put out for you. Anonymous ftp to dialup.oar.net and grab
pub/enable.tar.
It is a program written by a staff member here at OSU years ago and
modified for solaris by another staff member (who actually didn't like
solaris is the 5.3 days, as you can see from the comments in it).
Compile it and put it in a safe place. The default is /usr/local/etc,
but
you can change that in the code. Since solaris has an enable command
(for
printers) I've been calling it Enable. chmod 4750 the program, change
its
group ownership to something reasonable (I use staff), and create a file
named "enablelist" with the names of the people that should be able to
use
the command to become root. (enablelist is chmod 600.)
Type Enable (my name for it here) and you're root with your own
environment. (Well, most of it. A few minor things like aliases don't
make it in korn shell.)
I've been using it for nearly five years now and haven't had any
problems.
======================================================================
From: Gustavo Chaves <gustavo@cpqd.com.br>
Ed> Our users want to change the root shell to /bin/ksh. My question
Ed> is this: Is the Korn shell a strict superset of the Bourne
Ed> shell? In other words, will the Korn shell _always_ execute a
Ed> Bourne shell script _exactly_ the same and the Bourne shell
Ed> itself? Not all of the scripts in /etc/init.d and /etc/rc*
Ed> specify a shell; do any differences between sh and ksh really
Ed> matter?
Most probably not. We've been using /bin/csh as the root's shell for
a long time in 400+ machines running SunOS 4, SunOS 5, AIX, OSF/1, and
HP-UX. Not that I recommend using C-shell (in fact, I hope to
be able to substitute bash for it in the near future).
The scripts below /etc/rc?.d are passed explicitly as arguments to sh
by the scripts /etc/rc? during boot. Changing root's login shell
won't affect this.
Hope it helps.
======================================================================
From: "David F. Abner" <abner@voicenet.com>
The Korn Shell was written by David Korn at AT&T with the design goal
that
it would be completely backward compatible with the Bourne shell. I
have
found this to be the case. However, the Korn shell allows you to set
aliases and many other features not available in the Bourne shell. This
can
cause problems if the environment is not exported. For example, a
person
writes a script that executes perfectly in the Korn shell, but when
executed
in the Bourne shell it fails because the Bourne shell doesn't support
the
same environment (aliases, variables, etc.). How do you prevent users
with
root access from creating aliases and variables in the korn shell on one
system and creating a different set of variables and aliases on another
system. Korn shell scripts that run fine on one system fail on another.
Chaos . . .
======================================================================
From: timlee@netcom.com.DELETE-THIS.BIT (Timothy J. Lee)
On computers where a user who needs root access wants to use a
shell other than /sbin/sh, one option is to create another root
account with the desired shell. For example (in the /etc/passwd
file, with corresponding entries in the /etc/shadow file):
root:x:0:1:Super-User:/:/sbin/sh
rootksh:x:0:1:Super-User:/:/usr/bin/ksh
But you do have to remember to change both root passwords when
you want to change the root password.
======================================================================
From: Greg Onufer <Greg.Onufer@Eng.Sun.COM>
>Our users want to change the root shell to /bin/ksh.
So? Leave root alone and create a "kroot" user with the same uid/gid
as root but with ksh as the login shell. That way your systems don't
have some non-standard configuration (you can login as root and always
get what you expect) and your users can have a root account with the
shell they prefer. Best of all the worlds.
======================================================================
From: Stephen P Richardson <spr@myxa.com>
Why not just tell those who want another shell to just
"exec" the shell that they want when they need it?
I would leave the passwd entry alone.
======================================================================
From: KELEMEN Peter <fuji@chiara.csoma.elte.hu>
My suggestion: never ever change the factory default root shell. Create
an other account with uid 0 for system management purposes (I myself use
`system' for that), and change the shell of this account to whatever you
want. Keep root's and system's password in sync, and use root only when
a disaster takes place (lost /usr partition, etc.).
======================================================================
From: Philip Isaac <pisaacNOT@kodak.com>
How about the user typing in /bin/ksh after logging in as root? It works
in multi-admin groups because some prefer csh, tsch, or bash. Otherwise,
maybe set up a menu in the .profile so they can select a shell when they
log in.
======================================================================
From: Scott Boss <sboss@technologist.com>
If the system has a problem while trying to boot and the system
comes
up in maintenance mode, most filesystems are not mounted and using
shells that are dynamically linked may not work. At that point your
machine is hosed (<-- that is a technical term). I will not allow
anyone (the other sys admins) to change the shell from /sbin/sh to
/bin/csh (or ksh) for this reason. They just execute the shell once
they login. The other option you have is to have a bit of code in the
.profile to execute /bin/csh (or ksh) if it exsists. This would allow
the users to have a non-/sbin/sh shell for root if the system is up and
running fine but will not keep you out in the emergancies..
======================================================================
From: mwang@alhena.ibk.ml.com (Michael Wang)
If the rc script ends with sh, then . is used. if it does not end
with sh, then sh is used. My question is, under what shell . is used?
I do not think it is root shell as defined in passwd etc. But again
what shell? Thanks.
case ${f} in
*.sh) . ${f} ;; # source
it
*) /sbin/sh ${f} start ;; # sub
shell
esac
======================================================================
From: Art Mulder <art.mulder@ualberta.ca>
I don't know _why_ your users (a) want to change the shell
and (b) need to be root in the first place. So I don't know
if my suggestion will be of any use.
I install 'sudo' on my systems. Then I spend 90% or more of
my time just logged in as myself. This had the advantage of
giving me all my own personal environment customizations.
When I need to do a root task, I just use sudo, as
in "sudo vi /etc/vfstab". If I really absolutely must have
a root shell, then I just enter "sudo tcsh". This gives
me root priveleges, as well as a shell that I prefer.
Furthermore, sudo logs to a file, so that I could track who was
root and what was done, in case something gets inadvertenly broken.
======================================================================
Regards,
Ed
-- Ed Finch
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:36 CDT