bypass shell in /etc/passwd?
kal...@my-deja.com
ksh shell was not under '/sbin'. It tell me 'no shell' if I am trying
to login as root. Now I am stack. I still remember the password.
Do anyone know how to bypass the shell specified in /etc/passwd? Or Get
around with this problem? Thank you alot.
Sent via Deja.com http://www.deja.com/
Before you buy.
hume.sp...@bofh.halifax.ns.ca
> Do anyone know how to bypass the shell specified in /etc/passwd? Or Get
> around with this problem? Thank you alot.
Boot from CD, mount the partition, edit /etc/passwd.
--
Brandon Hume - hume -> BOFH.Halifax.NS.Ca, http://WWW.BOFH.Halifax.NS.Ca/
-> Solaris Snob and general NOCMonkey
James A. Williams
single-user from cdrom, mount the /etc filesystem and change root's shell to
what it is supposed to be.
kal...@my-deja.com wrote:
>
> I changed the root shell '/sbin/sh' to '/sbin/ksh'. But,
> ksh shell was not under '/sbin'. It tell me 'no shell' if I am trying
> to login as root. Now I am stack. I still remember the password.
>
> Do anyone know how to bypass the shell specified in /etc/passwd? Or Get
> around with this problem? Thank you alot.
>
Jack Gavin
I don't know if this will work, but it's worth a try:
1) Log in as yourself (not root).
2) su root (not 'su -')
This, I hope, will leave you in *your* login's variety of shell, but with
all the privileges of root. I could be wrong.
3) vi /etc/passwd
--
Jack Gavin
Jack Gavin
Oops! Just tried this, and it didn't keep the other shell. Sorry.
--
Jack Gavin
Srikant Sharma
then doing 'su' (not 'su -') can help as well .. you can get root access and
then edit the /etc/passwd file.
--
Srikant
On 26 Apr 2000 hume.sp...@bofh.halifax.ns.ca wrote:
> kal...@my-deja.com wrote:
> > Do anyone know how to bypass the shell specified in /etc/passwd? Or Get
> > around with this problem? Thank you alot.
>
Logan Shaw
James A. Williams <jawil...@lucent.com> wrote:
>You're right, you're stuck. The only way I know to recover is to boot
>single-user from cdrom, mount the /etc filesystem and change root's shell to
>what it is supposed to be.
Well, that's not the *only* way to recover. If the machine is an NIS
client, you can add a second root user to the NIS passwd table, log in
with that, delete it from the NIS table, and then fix the problem while
still logged in.
Or if your root filesystem is exported so that root can write files,
you can fix /etc/passwd. Or, if you can write into /sbin, you can make
a link from /sbin/ksh to /bin/ksh.
But yeah, it's the only solution that will work for everybody (at least
for everybody that has a CD-ROM drive).
- Logan
hume.sp...@bofh.halifax.ns.ca
> then doing 'su' (not 'su -') can help as well .. you can get root access and
> then edit the /etc/passwd file.
No, you can't. You can't su if root's shell is invalid.
hume.sp...@bofh.halifax.ns.ca
> client, you can add a second root user to the NIS passwd table, log in
> with that, delete it from the NIS table, and then fix the problem while
Also, if there are any known root exploits that you haven't patched for,
you can use those. (An unpatched eject saved me one day when I forgot my
root password. :) )
chris ulrich
%%I changed the root shell '/sbin/sh' to '/sbin/ksh'. But,
%%ksh shell was not under '/sbin'. It tell me 'no shell' if I am trying
%%to login as root. Now I am stack. I still remember the password.
%%
%%Do anyone know how to bypass the shell specified in /etc/passwd? Or Get
%%around with this problem? Thank you alot.
If you've got any accounts that are in group sysadmin and you've
left the suid root bit on admintool I believe you can probably either
add your own account to group sys (where /sbin is owned group sys and
goup writable for some stupid reason, so you'd be able to create
the shell /sbin/ksh for the time it would be needed to undo your
goof) or you could create a uid zero account maybe. I've never used
admintool too much, so I'm not sure what all it can do.
chris
Thomas (Xiaoxi) Hu
(not mine) Check for recently posted message in this group. There
was one talking about lost root password. That should apply to your
situation.
Lessons we have learnt:
(1) A "which ksh" or "whereis ksh" could have given out
the path to ksh before passwd file was changed.
(2) After any change to root account, one action login session
should be kept before a new login is verified.
(3) It's be better to leave root login shell as it has been. Not any
shell is available in single user mode. As root, you do need a
working shell in single user mode.
I have seen people wanted ksh as root login shell twice
since my first step in this group week ago. I really hope
it is just a "nice try"
Thomas
<kal...@my-deja.com> wrote in message news:8e7afg$hfr$1...@nnrp1.deja.com...
> I changed the root shell '/sbin/sh' to '/sbin/ksh'. But,
> ksh shell was not under '/sbin'. It tell me 'no shell' if I am trying
> to login as root. Now I am stack. I still remember the password.
>
> Do anyone know how to bypass the shell specified in /etc/passwd? Or Get
> around with this problem? Thank you alot.
>
>
Joe Bouchard
>>
>> I changed the root shell '/sbin/sh' to '/sbin/ksh'. But,
>> ksh shell was not under '/sbin'. It tell me 'no shell' if I am trying
>> to login as root. Now I am stack. I still remember the password.
>>
>> Do anyone know how to bypass the shell specified in /etc/passwd? Or Get
>> around with this problem? Thank you alot.
If a user has "sudo" privileges then he could "sudo vi /etc/passwd".
--
Thank you,
Joe Bouchard
Powered by Debian GNU/Linux
Joe Durusau
the root shell alone. It also points out, that once you have
made the mistake of mangling the root shell, your choices are:
1). If you are running NIS, get in from another system and fix..
2). Boot from the CDROM, fix the file.
3). Drag the disk off to an undamaged system and mount it there.
Note that su always uses the shell from /etc/passwd, even in single-
user mode.
Making a note to leave the root shell alone is highly recommended.
See the thread on Deja (Which must be s tupemdous thing by now)
entitled 'root shell disease'.
Speaking only for myself,
Joe Durusau
lmac...@pnmt.com
to do:
bring the system down to bootprom
#init 0
now at the ok prompt you will need the boot/os cd
ok boot cdrom -s
this will take you to single user mode on the cd. This takes a while
but not as long as a install boot.
when the prompt comes up do the following:
#cd /tmp
#mkdir <dir_name>
You need to know what the root device name is
#mount /dev/rdsk/c0t0d0s0 /tmp/<dir_name>
#cd <dir_name> (as you should already be in /tmp)
#cd etc (remeber do not use the "/" you do not want to go to the root
directory)
#vi passwd
change your shell back
#reboot
the system should come back up with no worry's.
and a sub-note NEVER CHANGE ROOT SHELL EVER!!!!!
you want to use a different shell type it in at the command line
#ksh
#csh
#bash
#tsch
bourne is the default.
There are many reasons to not change the root shell all you need to know
is to never do it again. Now remember this is more than some jerk-off
telling you that was dumb. Because I did it too. I just knew how to
fix it. And now you do too. Aint UNIX grand.
In article <8e7afg$hfr$1...@nnrp1.deja.com>,
kal...@my-deja.com wrote:
> I changed the root shell '/sbin/sh' to '/sbin/ksh'. But,
> ksh shell was not under '/sbin'. It tell me 'no shell' if I am trying
> to login as root. Now I am stack. I still remember the password.
>
> Do anyone know how to bypass the shell specified in /etc/passwd? Or
Get
> around with this problem? Thank you alot.
>
Gopala
available in /bin, simple rule.
I have tried with ksh and it works just fine. Remember while system
bootup, INIT 1 system only has the ROOT fs available to it. And /bin is
integral to ROOT. IF your shell is in /bin and does not need any
libraries from anyother FS eg., /usr then you can do it.
Gopi.
In article <8f9egi$e9u$1...@nnrp1.deja.com>,
--
Gopala Molakaluri
Michigan
Thomas (Xiaoxi) Hu
A UNIX admin should only assume availability of /sbin/sh
when it comes to the default login shell.
In normal mode, multi user mode, other shells might be ok
(still not 100%). In single user mode or emergency recovering,
we can only survive with /sbin
It (changing root login shell) is certainly open to discussion but
I would like to see warning (such as from Dan) rather than
being told how to implement it.
Thomas
<See-signa...@nospam.net> wrote in message
news:eB7S4.8644$ZE4.1...@ord-read.news.verio.net...
> Gopala <gmol...@my-deja.com> wrote:
> > You may change your root default shell but just make sure that it is
> > available in /bin, simple rule.
> > I have tried with ksh and it works just fine. Remember while system
> > bootup, INIT 1 system only has the ROOT fs available to it. And /bin is
> > integral to ROOT. IF your shell is in /bin and does not need any
> > libraries from anyother FS eg., /usr then you can do it.
>
> I'm afraid you're mistaken. /bin is a symlink to /usr/bin on every
Solaris
> system I have ever used.
>
> Perhaps you meant /sbin which is part of the / partition. The only shell
> guaranteed to work is /sbin/sh (statically linked, always lives on the /
> partition).
>
> If you want other shells to behave similarly, link them statically and
> stick them in /sbin as well.
>
> --
> Dan Lowe < dan at scsiboy dot com > -- http://scsiboy.com/
Michael Joosten
>
> Perhaps you meant /sbin which is part of the / partition. The only shell
> guaranteed to work is /sbin/sh (statically linked, always lives on the /
> partition).
>
Not quite... I routinely use /sbin/jsh as root's shell, because doing a
'su' and having a shell that doesn't know about job control is a little
inconvenient for me...
And, before now somebody think I'm still stupid after these posts, do a
ls -l in /sbin and you'll know why I don' worry about jsh ...
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Michael Joosten | Tel. : (+49) (+) 5251-60-6127 |
| C-LAB | Fax : (+49) (+) 5251-60-6065 |
| Fuerstenalle 11 | E-Mail: jo...@c-lab.de |
| 33094 Paderborn | C-LAB is a cooperation between |
| Germany | University Paderborn & SIEMENS AG |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
root (jerrys)
>
> See-signa...@nospam.net wrote:
<snip>
>
> Not quite... I routinely use /sbin/jsh as root's shell, because doing a
> 'su' and having a shell that doesn't know about job control is a little
> inconvenient for me...
>
> And, before now somebody think I'm still stupid after these posts, do a
> ls -l in /sbin and you'll know why I don' worry about jsh ...
I can readily see that it's a hard link. But clearly it invokes
different behavior.
It doesn't pose a risk as far as preventing root login on a crippled
system. But can anyone say for certain that it does not pose additional
security risks?
--
Jerry Sutton k5...@swbell.net
Of course, I don't speak on behalf of my employer.
Roger Marquis
>I hope everyone understand the point made by Dan here.
>A UNIX admin should only assume availability of /sbin/sh
>when it comes to the default login shell.
This is a good example of the misinformation that causes junior
sysadmins to fear changing the root shell. In reality:
* Most sites change the Solaris root shell to (in order):
/bin/csh, /bin/tcsh or /bin/bash
* If you change the root shell from /sbin/sh makes sure
that the new shell is either statically linked or that:
A) /usr/lib is on the root partition, and
B) the shell is also on the root partition
By following these guidelines you can safely change the Solaris
from its default. Good reasons for changing the root shell include:
* compatibility with your user shell,
* compatibility across operating systems (for example freebsd's
csh or linux' bash), and
* access to enhanced shell features such as command line
completion, command line editing, scroll back history buffer,
and command line metacharacters.
Beware of admins warning of dire consequences from changing the
Solaris root shell. They often don't understand linked libraries
and single-user mode, have limited experience working with root
privileges, or they are not aware of the productivity enhancing
features of modern Unix shells.
IMHO,
--
Roger Marquis
Roble Systems Consulting
http://www.roble.com/
Fredrich P. Maney
: Xiaoxi\ Hu <to...@globility.com> wrote:
:>I hope everyone understand the point made by Dan here.
:>A UNIX admin should only assume availability of /sbin/sh
:>when it comes to the default login shell.
: This is a good example of the misinformation that causes junior
: sysadmins to fear changing the root shell. In reality:
: * Most sites change the Solaris root shell to (in order):
: /bin/csh, /bin/tcsh or /bin/bash
I guess we have different definitions of "most". I've worked at numerous
Solaris sites (both very large and very small installations) and have
never seen the root shell changed on any of the machines by anyone other
than a few "I have Linux running at home on my PC, so I know how to be
an SA and I simply *must* have bash as the root shell" types who promptly
got smacked around and moved off to someplace where they couldn't do any
more damage.
: * If you change the root shell from /sbin/sh makes sure
: that the new shell is either statically linked or that:
: A) /usr/lib is on the root partition, and
: B) the shell is also on the root partition
: By following these guidelines you can safely change the Solaris
: from its default.
You forgot another step, namely going through the entire system and
making sure that all of the scripts (/etc/init.d, /etc/rc*.d/*, crontabs,
etc.) that are run by the system forcibly use the right shell instead
of defaulting to the shell of the user that executed them.
: Good reasons for changing the root shell include:
Looks like your definition of "good" and mine don't match either.
: * compatibility with your user shell,
*NOT* a good thing. This contributes to SAs (or at least people who think
they are SAs) spending way too much time logged in as root. That is a
*very* bad habit.
: * compatibility across operating systems (for example freebsd's
: csh or linux' bash), and
And why do you need this? If you are doing something as root, you should
be doing something that affects the local machine, not a remote one. If
you need to be affecting a remote machine, you should be logged in as root
on that machine instead.
If you want this compatiblity for scripting purposes, all you have to do
use some brains and write your scripts so that they intelligently (and
explicitly) call the correct shell when executed.
: * access to enhanced shell features such as command line
: completion, command line editing, scroll back history buffer,
: and command line metacharacters.
All of which are quite easily accomplished by simply creating the proper
profile for your preferred shell and then simply executing that shell
upon becoming root.
: Beware of admins warning of dire consequences from changing the
: Solaris root shell. They often don't understand linked libraries
: and single-user mode, have limited experience working with root
: privileges, or they are not aware of the productivity enhancing
: features of modern Unix shells.
Or, they are highly experienced and realize that the supposed benefits
are far outweighed by the risks and problems associated with changing
root's shell.
fpsm
--
| Fredrich P. Maney |
| ma...@stdio.com ma...@maney.org www.maney.org ICQ# 5632845 |
| Fight Spam! Join CAUCE! == http://www.cauce.org/ |
| Outlaw Junk Email! Support HR1748. |
| "Sometimes, fear has a good and useful purpose." |
Casper H.S. Dik - Network Security Engineer
"Fredrich P. Maney" <ma...@heathers.stdio.com> writes:
>You forgot another step, namely going through the entire system and
>making sure that all of the scripts (/etc/init.d, /etc/rc*.d/*, crontabs,
>etc.) that are run by the system forcibly use the right shell instead
>of defaulting to the shell of the user that executed them.
Which other people have donebfore him; root's shell is hardly ever used
for anything. Su root and login as root come to mind.
ron also uses /bin/sh, always, it seems.
>*NOT* a good thing. This contributes to SAs (or at least people who think
>they are SAs) spending way too much time logged in as root. That is a
>*very* bad habit.
Indeed; forcing root to have a shell w/o command history and editing
may change their mind about that.
Besides, there are other ways to get roo t to run a comfy environment.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Andrew Gabriel
Roger Marquis <not-fo...@roble.com> writes:
> Xiaoxi\ Hu <to...@globility.com> wrote:
>>I hope everyone understand the point made by Dan here.
>>A UNIX admin should only assume availability of /sbin/sh
>>when it comes to the default login shell.
>
> This is a good example of the misinformation that causes junior
> sysadmins to fear changing the root shell. In reality:
>
> * Most sites change the Solaris root shell to (in order):
> /bin/csh, /bin/tcsh or /bin/bash
Home users often do. I happen to know that most real sites don't
as changing to anything which doesn't accept borne shell syntax
brakes too many things (third party things nowdays, but sadly some
Sun-shipped things in the past).
> * If you change the root shell from /sbin/sh makes sure
> that the new shell is either statically linked or that:
I don't think any shells other than borne shell can be statically
linked on Solaris (unless you start pulling out bits of them).
I've had to fix too many screwups caused by inexperienced admins
changing root's shell (not counting the times when an admin
screws up the change itself, all too familiar in this forum :-).
A secondary problem is that they then use root too much, rather
than for only those things which should be done as root, and
that can lead to more 'accidents'.
--
Andrew Gabriel
Consultant Software Engineer
Thomas Dehn
"Roger Marquis" <not-fo...@roble.com> schrieb im Newsbeitrag
news:ViTU4.18191$jZ3.2...@nuq-read.news.verio.net...
> Xiaoxi\ Hu <to...@globility.com> wrote:
> >I hope everyone understand the point made by Dan here.
> >A UNIX admin should only assume availability of /sbin/sh
> >when it comes to the default login shell.
>
> This is a good example of the misinformation that causes junior
> sysadmins to fear changing the root shell. In reality:
>
> * Most sites change the Solaris root shell to (in order):
> /bin/csh, /bin/tcsh or /bin/bash
Changing the login shell to an unsupported
shell (tcsh before 2.6 resp. bash before 8) is not good idea.
Thomas
Fredrich P. Maney
[deletia]
: Changing the login shell to an unsupported
: shell (tcsh before 2.6 resp. bash before 8) is not good idea.
You could have said it much more simply:
Changing root's shell is not a good idea.
Fredrich P. Maney
: [[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]
: "Fredrich P. Maney" <ma...@heathers.stdio.com> writes:
:>You forgot another step, namely going through the entire system and
:>making sure that all of the scripts (/etc/init.d, /etc/rc*.d/*, crontabs,
:>etc.) that are run by the system forcibly use the right shell instead
:>of defaulting to the shell of the user that executed them.
I forgot to point out that you will have to do this again every single
time you add new software/patches.
: Which other people have donebfore him; root's shell is hardly ever used
: for anything. Su root and login as root come to mind.
The problem though is that it is a recurring problem. There are too
many software packages (including a few Sun packages and patches) that
are built to use /sbin/sh but do not actually call it themselves when
they are installed/run that will break if you change root's login shell.
: ron also uses /bin/sh, always, it seems.
I'm not sure. I vaguely recall having problems with cron running /bin/sh
and /sbin/sh and even /sbin/ksh before. That was several years ago though,
so I might be wrong (or talking about something from another Unix flavour).
:>*NOT* a good thing. This contributes to SAs (or at least people who think
:>they are SAs) spending way too much time logged in as root. That is a
:>*very* bad habit.
: Indeed; forcing root to have a shell w/o command history and editing
: may change their mind about that.
One can hope.
: Besides, there are other ways to get roo t to run a comfy environment.
Yep, use "su root" insted of "su - root", or su to root and then exec
the configured shell of choice.
Andrews
>
>Which can be problematic when you're working in large environments.
>If you have to make manual changes to hundreds of hosts at a time
>the reasons for changing the root shell, and not invoking a sub-shell,
>become clearer.
>
I don't agree. Create another entry in the passwd file/map/table
with uid 0 and your preferred shell. Give it a login name to make
the entry's function obvious ('rootksh', 'rootbash', or whatever),
and its own home directory and dotfiles to establish the consistent
working environment.
Leave the plain 'root' entry with the shell that will work in emergencies
(/sbin/sh) in the passwd file, and only use it for emergencies.
This satisfies your requirements for a useful, universal environment
for working on each machine, and still leaves the root entry's shell
alone.
-Greg
--
::::::::::::::::::: Greg Andrews ge...@wco.com :::::::::::::::::::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Kenny McCormack
Fredrich P. Maney <ma...@heathers.stdio.com> wrote:
>On Thu, 18 May 2000 18:59:00 +0200 in comp.unix.solaris Thomas Dehn <thomas...@myokay.net> wrote:
>
>[deletia]
>
>: Changing the login shell to an unsupported
>: shell (tcsh before 2.6 resp. bash before 8) is not good idea.
>
>You could have said it much more simply:
>
>Changing root's shell is not a good idea.
Shouldn't that really read:
Changing root's shell is not a good idea unless you have a bootable
CD available and know how to use it.
One of my standard ideas is that it is OK to get yourself into a mess
provided you know how to get yourself out of it.
Roger Marquis
>: from its default.
>
>making sure that all of the scripts (/etc/init.d, /etc/rc*.d/*, crontabs,
>etc.) that are run by the system forcibly use the right shell instead
>of defaulting to the shell of the user that executed them.
This is another example of the misinformation that causes inexperienced
admins to fear changing the root shell under Solaris. Unless you're
running 2.4 or earlier all rc scripts are executed under /sbin/sh,
regardless of what the root shell is set to in /etc/passwd (see
/etc/rc? for details).
>And why do you need this? If you are doing something as root, you should
>be doing something that affects the local machine, not a remote one.
Whether it's a local machine or a remote machine makes no difference.
If someone asks about changing the root shell they must have a
reason for wanting to do it.
>All of which are quite easily accomplished by simply creating the proper
>profile for your preferred shell and then simply executing that shell
>upon becoming root.
Which can be problematic when you're working in large environments.
If you have to make manual changes to hundreds of hosts at a time
the reasons for changing the root shell, and not invoking a sub-shell,
become clearer.
>Or, they are highly experienced and realize that the supposed benefits
>are far outweighed by the risks and problems associated with changing
>root's shell.
We've heard a number of bogus reason for not changing the root
shell: mis-edited password files, rc scripts, cron scripts, and of
course "just don't". I've yet to hear a good reason for not changing
the root shell. All of which illustrate the level of FUD that
makes this such an old wives' tale.
Russ Allbery
> Roger Marquis <not-fo...@roble.com> writes:
>> Which can be problematic when you're working in large environments. If
>> you have to make manual changes to hundreds of hosts at a time the
>> reasons for changing the root shell, and not invoking a sub-shell,
>> become clearer.
> I don't agree. Create another entry in the passwd file/map/table with
> uid 0 and your preferred shell. Give it a login name to make the
> entry's function obvious ('rootksh', 'rootbash', or whatever), and its
> own home directory and dotfiles to establish the consistent working
> environment.
That's the *worst* possible solution to the problem. Extra UID 0 accounts
are inherent security holes; they have separate passwords that don't get
updated when the root password is updated, they get around programs that
disallow things done as the user "root" (a stupid way of testing it, but
I've seen software that does this), and they defeat some of the point of
having a single choke-point of access to god privileges.
The best solution is to define a single-letter alias in the root shell
that sets up your environment, changing shells if necessary, as well as
setting your path, setting up your aliases, and all the other sugar needed
for good interactivity. We use "b" as that alias. You can even have it
take an optional argument to specify one particular set of settings.
We still always change the root shell of all our Solaris machines to tcsh.
We've been doing this for years, I've done this for years for every
machine I've administered, and despite the mistakes of amateur sysadmins
that we see in this newsgroup, I've never had a problem from doing that.
It's quite possible to change the root shell of a Solaris system without
any difficulties, and I personally find it convenient even when issuing
single commands as root to have command-line editing available. The flat
statement that one should never, ever change the root shell is pure
nonsense; if you're an amateur and you're not sure of what you're doing,
then by all means leave it alone, but it's really not that big of a deal.
But regardless, you don't have to change the root shell. If you define a
single-character alias and just always use it after you su, you may not
even notice you're using a substandard interactive shell by default.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Kjetil Torgrim Homme
> We still always change the root shell of all our Solaris machines
> to tcsh.
Urg. So you have to use C-shell syntax for all repetetive tasks? How
do you stand it?
I often run relatively involved one-liners on all our Unix-hosts (for
m in `ng allhosts`; do rsh -n $m ...; done), and it is important that
they all run the same root shell dialect.
We type "exec bash" to get a more friendly environment. Certain
daemons do not clear their environment (inetd, cron), so care should
be taken to restart them outside that friendly environment.
Kjetil T.
Fredrich P. Maney
: Fredrich P. Maney <ma...@heathers.stdio.com> wrote:
:>: By following these guidelines you can safely change the Solaris
:>: from its default.
:>
:>You forgot another step, namely going through the entire system and
:>making sure that all of the scripts (/etc/init.d, /etc/rc*.d/*, crontabs,
:>etc.) that are run by the system forcibly use the right shell instead
:>of defaulting to the shell of the user that executed them.
: This is another example of the misinformation that causes inexperienced
: admins to fear changing the root shell under Solaris. Unless you're
: running 2.4 or earlier all rc scripts are executed under /sbin/sh,
: regardless of what the root shell is set to in /etc/passwd (see
: /etc/rc? for details).
This is another example of an arrogant pompous ass intentionally giving
enough rope to hang himself.
BTW, while this seems to be true for the Sun supplied rc files in 2.5.1 and
above, it is most definitely not true for the third-party vendor supplied
rc files that I found. Also, there are still many people who are running
2.4 in production. Your blase response of "this is perfectly safe" is
tantamount to handing a loaded gun to a child and saying, this is perfectly
safe as long as you don't pull the trigger.
:>And why do you need this? If you are doing something as root, you should
:>be doing something that affects the local machine, not a remote one.
: Whether it's a local machine or a remote machine makes no difference.
IF you had read my response (instead of snipping it without even the courtesy
of showing that you had done so), you would have noticed that I said there
are proper ways to do things. Namely if you are trying to change something
on another machine, you should do so *from that machine*, not the local
machine.
: If someone asks about changing the root shell they must have a
: reason for wanting to do it.
And, I have yet to find anyone that had a good reason for this. Just because
someone wants to intentionally unhook the safety buckles on their bungee
cord before they jump, doesn't mean you should show them how.
:>All of which are quite easily accomplished by simply creating the proper
:>profile for your preferred shell and then simply executing that shell
:>upon becoming root.
: Which can be problematic when you're working in large environments.
Far less so than dealing with having incompatible and dangerous configurations
on every machine.
: If you have to make manual changes to hundreds of hosts at a time
: the reasons for changing the root shell, and not invoking a sub-shell,
: become clearer.
Really? I've always found that using tools like ctelnet (from the Sun
Cluster Package), supper/dsh/dshbak (from the IBM PSSP Package) and
homegrown knockoffs have accomplished this quite handily, *without* having
to resort to changing root's shell.
:>Or, they are highly experienced and realize that the supposed benefits
:>are far outweighed by the risks and problems associated with changing
:>root's shell.
: We've heard a number of bogus reason for not changing the root
: shell: mis-edited password files, rc scripts, cron scripts, and of
: course "just don't". I've yet to hear a good reason for not changing
: the root shell. All of which illustrate the level of FUD that
: makes this such an old wives' tale.
I have given you several of them. All of them come from my personal
experience as a Unix Systems Administrator in better than 10 different
flavours of Unix in the last 7 years on hardware ranging from desktops
to the bleeding edge and in (hetero- and homogeneous) networks ranging
in size from 1 to several thousand. I am not the only person who has
done so, however you keep choosing to ignore us. That's fine. You are
more than welcome to spend your time thumbing your nose at us, however,
when (not if) this comes back to bite you, I strongly suggest that you
do not come back here looking for help. You will probably only get
weeks worth of laughter and ridicule.
Fredrich P. Maney
: Roger Marquis <not-fo...@roble.com> writes:
:>
:>Which can be problematic when you're working in large environments.
:>If you have to make manual changes to hundreds of hosts at a time
:>the reasons for changing the root shell, and not invoking a sub-shell,
:>become clearer.
: I don't agree. Create another entry in the passwd file/map/table
: with uid 0 and your preferred shell. Give it a login name to make
: the entry's function obvious ('rootksh', 'rootbash', or whatever),
: and its own home directory and dotfiles to establish the consistent
: working environment.
: Leave the plain 'root' entry with the shell that will work in emergencies
: (/sbin/sh) in the passwd file, and only use it for emergencies.
: This satisfies your requirements for a useful, universal environment
: for working on each machine, and still leaves the root entry's shell
: alone.
However, it also violates some of biggest security requirements in the
book. While this is a fairly safe (from the OS point of view) approach,
from a security POV it is *very* dangerous.
Fredrich P. Maney
: In article <8g19lr$odp$1...@newsread.stdio.com>,
:>
:>[deletia]
:>
:>: Changing the login shell to an unsupported
:>: shell (tcsh before 2.6 resp. bash before 8) is not good idea.
:>
:>You could have said it much more simply:
:>
:>Changing root's shell is not a good idea.
: Shouldn't that really read:
: Changing root's shell is not a good idea unless you have a bootable
: CD available and know how to use it.
Provided of course that every machine has a CDROM (which is most certianly
not the case in a lot of large shops that extensively use JumpStart
for their builds and configurations).
: One of my standard ideas is that it is OK to get yourself into a mess
: provided you know how to get yourself out of it.
If you are the only one supporting the systems, maybe. However, in most
shops (including where I am now) there are many people who have to
support a given environment (roughly 30 here with root, and another 200
or so with sudo) and *have* to be able to recover a machine in the event
of an emergency. That means that all of the systems have to be standard.
And the more non-standard they become, the more documentation that has
to be written, read and maintained.
chris ulrich
%%making sure that all of the scripts (/etc/init.d, /etc/rc*.d/*, crontabs,
%%etc.) that are run by the system forcibly use the right shell instead
%%of defaulting to the shell of the user that executed them.
This isn't actually correct.
The rc# scripts change to the rc#.d directory and run the following
loop: (for example, the rc1 script)
for f in /etc/rc1.d/K*
{
if [ -s ${f} ]
then
case ${f} in
*.sh) . ${f} ;;
*) /sbin/sh ${f} stop ;;
esac
fi
}
Which means that so long as init runs /sbin/sh (which it does because
it is hard-coded to do so) the init scripts will *always* run correctly.
There are lots of reasons not to change the root shell, but this is
not one of them.
chris
Rich Teer
> This isn't actually correct.
> The rc# scripts change to the rc#.d directory and run the following
> loop: (for example, the rc1 script)
>
> for f in /etc/rc1.d/K*
> {
> if [ -s ${f} ]
> then
> case ${f} in
> *.sh) . ${f} ;;
> *) /sbin/sh ${f} stop ;;
> esac
> fi
> }
>
> Which means that so long as init runs /sbin/sh (which it does because
> it is hard-coded to do so) the init scripts will *always* run correctly.
At boot time, I agree. But what about stopping/starting a service using
/etc/rc2.d/SnnServiceName stop | start when using a funky shell, where
/etc/rc2.d/SnnServiceName doesn't say #!/shell/name? Bad script writing
practise, I agree, but still...
--
Rich Teer
NT tries to do almost everything UNIX does, but fails - miserably.
The use of Windoze cripples the mind; its use should, therefore, be
regarded as a criminal offence. (With apologies to Edsger W. Dijkstra)
If it ain't analogue, it ain't music.
Voice: +1 (250) 763-6205
WWW: www.rite-group.com
Fredrich P. Maney
: On 19 May 2000, chris ulrich wrote:
:> This isn't actually correct.
:> The rc# scripts change to the rc#.d directory and run the following
:> loop: (for example, the rc1 script)
:>
:> for f in /etc/rc1.d/K*
:> {
:> if [ -s ${f} ]
:> then
:> case ${f} in
:> *.sh) . ${f} ;;
:> *) /sbin/sh ${f} stop ;;
:> esac
:> fi
:> }
:>
:> Which means that so long as init runs /sbin/sh (which it does because
:> it is hard-coded to do so) the init scripts will *always* run correctly.
: At boot time, I agree. But what about stopping/starting a service using
: /etc/rc2.d/SnnServiceName stop | start when using a funky shell, where
: /etc/rc2.d/SnnServiceName doesn't say #!/shell/name? Bad script writing
: practise, I agree, but still...
Bad script writing practice, however, he is right that it is the practice
that is used for the Sun supplied init scripts. Some of the third party
vendor init scripts I've seen also do this, however most of the homegrown
scripts specifically specify the shell to use when being executed.
Interestingly enough, this practice is not carried through in the Sun
and third party vendor supplied scripts in /etc/init.d/ except in the
case of scripts that actually reside in one of the /etc/rc*.d/ directories
and are symlinked into /etc/init.d/. The ones that do actually reside
in /etc/init.d/ semm to all specifiy the actual shell to use when
executed.
And since we all know that the scripts in the /etc/rc*.d/ and /etc/init.d/
directories are used much more frequently than simply at boot time, it
strikes me that this *is* a very valid reason to leave root's shell
alone.
chris ulrich
%%directories are used much more frequently than simply at boot time, it
%%strikes me that this *is* a very valid reason to leave root's shell
%%alone.
%%| Fredrich P. Maney |
The kernel uses the system default shell, not the users's shell to
execute files that have no other identification (ie when file says
"commands text"). You can change the notion of "system default shell"
but this involves re-compiling everything, not simply changing the
root users's shell.
Try it yourself. Make an account with shell /bin/csh, then make an
executable file with contents
echo "$@"
then run it with some command line option. You will see that command
line option echoed. Now, change the file to have the line
#!/bin/csh
as the first line, and it will complain "variable syntax".
When you run a file with commands in it, the kernel (after forking
your shell, whatever it may be) will always exec /bin/sh to interpret
that file. Don't trust me, trust truss.
chris
chris ulrich
Rich Teer <ri...@rite-group.com> wrote:
>At boot time, I agree. But what about stopping/starting a service using
>/etc/rc2.d/SnnServiceName stop | start when using a funky shell, where
>/etc/rc2.d/SnnServiceName doesn't say #!/shell/name? Bad script writing
>practise, I agree, but still...
Again, this isn't an issue.
The kernel will try to execute the file, see that it isn't a binary,
will look at the first line, and if it is a : then it will execute the
default shell for the system (on bsd systems this tends to be csh, on
normal systems this tends to be /bin/sh). If it is a #, it will execute
/bin/sh, and if it is a #!/something then it will execute /something.
Failing that, it will try to pass it through to /bin/sh. This makes the
case of the root shell again not important for any situation involving
init scripts (unless you try to source them with csh and they are
bourne shell scripts, but if you are this far along, hopefully you
don't try such things anymore).
Of course, it is still a bad idea to change the root shell simply
because it is so trivial to get the desired effect (useful environment)
without resorting to such a crude mechanism. For example, I have as my
personal .profile a script that looks for the best available shell and
uses that. The .profile works on every unix I've run across, and if I
source it as root then it configures itself slightly differently but
still works. This way, I login as root or su, then
. /home/myhome/.profile
and everything is set.
chris
ger...@ike.portal.ca
Caspe...@Holland.Sun.Com (Casper H.S. Dik - Network Security Engineer) writes:
> [[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]
>
> may change their mind about that.
>
>
Um gee lemme think like typing :
"bash"
and having a /.bashrc???
Naw too hard - let's screw everything up instead...
Russ Allbery
> [Russ Allbery]
>> We still always change the root shell of all our Solaris machines
>> to tcsh.
> Urg. So you have to use C-shell syntax for all repetetive tasks? How
> do you stand it?
I'm very used to it. I find foreach quite reasonable for the stuff I do
on the command line, and just switch to "for" for shell scripts when I
write them. I'm pretty used to foreach syntax, being an extremely
experienced Perl programmer.
> I often run relatively involved one-liners on all our Unix-hosts (for
> m in `ng allhosts`; do rsh -n $m ...; done), and it is important that
> they all run the same root shell dialect.
foreach m (`ng allhosts`)
rsh -n $m ...
done
does work fine, you know. :)
tcsh still has better command completion than any other interactive shell
that I've seen except zsh, and zsh is just way overkill for me. bash is
getting somewhat better, but it's still not even in the same ballpark.
> We type "exec bash" to get a more friendly environment. Certain daemons
> do not clear their environment (inetd, cron), so care should be taken to
> restart them outside that friendly environment.
Yup, even more of an issue for us since we use AFS and don't want stuff
inheriting AFS tokens.
Russ Allbery
>> At boot time, I agree. But what about stopping/starting a service
>> using /etc/rc2.d/SnnServiceName stop | start when using a funky shell,
>> where /etc/rc2.d/SnnServiceName doesn't say #!/shell/name? Bad script
>> writing practise, I agree, but still...
> Bad script writing practice, however, he is right that it is the
> practice that is used for the Sun supplied init scripts. Some of the
> third party vendor init scripts I've seen also do this, however most of
> the homegrown scripts specifically specify the shell to use when being
> executed.
I've just gotten used to typing "sh /etc/init.d/service start" instead,
which also works around the problem of the scripts not being executable.
*shrug* It's really not that big of a deal.
> And since we all know that the scripts in the /etc/rc*.d/ and
> /etc/init.d/ directories are used much more frequently than simply at
> boot time, it strikes me that this *is* a very valid reason to leave
> root's shell alone.
Or fix the scripts, which has advantages of its own (I've found all and
ripped out all sorts of junk, sometimes potentially dangerous junk, from
vendor init scripts once I started looking at them).
Kjetil Torgrim Homme
> > Urg. So you have to use C-shell syntax for all repetetive tasks? How
> > do you stand it?
>
> I'm very used to it. I find foreach quite reasonable for the stuff I do
> on the command line, and just switch to "for" for shell scripts when I
> write them.
It's more than for vs. foreach. The baroque if, the redirection
braindamage, the lack of read(1)... This is rapidly getting
religious, so let's just agree to disagree.
> I'm pretty used to foreach syntax, being an extremely
> experienced Perl programmer.
for and foreach are interchangable in Perl, so I prefer the variant
which saves four bytes of disk space. ;-)
> > I often run relatively involved one-liners on all our Unix-hosts (for
> > m in `ng allhosts`; do rsh -n $m ...; done), and it is important that
> > they all run the same root shell dialect.
>
> foreach m (`ng allhosts`)
> rsh -n $m ...
> done
>
> does work fine, you know. :)
Of course it does, I replaced the important part with "..." :-)
Here's an actual example:
"/local/gnu/bin/df -P | awk '/^hungr:/ {print \$NF}' | while read p; do umount \$p; done"
Kjetil T.
Fredrich P. Maney
: Brandon Hume <hume.sp...@bofh.halifax.ns.ca> wrote:
:>And like I've said before... if you consider the "dire consequences" imaginary,
:>then you don't read this group very thoroughly, or even the initial posts of
:>this very thread.
: Both Brandon Hume and Fredrich P. Maney seem to be going to great
: lengths to turn this discussion into a character attack. IMHO,
: this speaks to the merits of their technical points. To summarize:
Really now? It seems to me that you were the one who started with the
insults and name calling. However......
[deletia]
I deleted the others because I have answered all of them before and you
have yet to be able to counter them with anything other than attitude.
This one however....
: FUD) There are many reasons to not change the root shell all you
: need to know is to never do it again.
: OPINION) Claims that anything is "all you need to know" are
: generally incorrect.
Much like when making a statement to the effect of "this is the list of
steps that you need to follow to change root's shell safely" when that
list is incomplete and inaccurate?
hume.sp...@bofh.halifax.ns.ca
> Both Brandon Hume and Fredrich P. Maney seem to be going to great
> lengths to turn this discussion into a character attack. IMHO,
> this speaks to the merits of their technical points.
Thank you. A person only needs to read those two sentences of yours to
determine why it might seem like we're defensive. I note with amusement that
you completely ignored MY primary statement in my post.
In any event, we've all had this tune played before. And like I've said
before, right or wrong, brilliance or idiocy, you'll stick to your position.
Its enough to make someone think you were a consultant or something.
--
Brandon Hume - hume -> BOFH.Halifax.NS.Ca, http://WWW.BOFH.Halifax.NS.Ca/
-> Solaris Snob and general NOCMonkey
Rich Teer
> FACT) As long as the root shell is correctly defined, on the root
> partition, and /usr/lib is on the root partition there is no
> problem booting single-user and logging-in root.
... Assuming that none of the required libraries are missing or corrupt.
If any are, then you will not be booting in single user mode (or at least,
logging in so that you can fix things)!
Roger Marquis
>> FACT) As long as the root shell is correctly defined, on the root
>> partition, and /usr/lib is on the root partition there is no
>> problem booting single-user and logging-in root.
>
>... Assuming that none of the required libraries are missing or corrupt.
>If any are, then you will not be booting in single user mode (or at least,
>logging in so that you can fix things)!
True, however, the likelihood of a deleted or corrupted library is
about the same as a deleted or corrupted shell. The chances of
either are pretty small. I wouldnt choose a shell, root or otherwise,
based on this criteria. Would you Rich?
Fredrich P. Maney
I think it is a perfectly reasonable call regardign root's shell. It's
simple. If you leave root's shell alone, you only have to worry about that
one file. If you change it, you have to worry about the new shell executable
and all of the libraries that it calls. Why take the extra risk simply because
you are too lazy to start your shell of choice after becoming root?
Rich Teer
> True, however, the likelihood of a deleted or corrupted library is
> about the same as a deleted or corrupted shell. The chances of
For suitably loose definitions of "about the same". If root's shell
is /sbin/sh, there is one, and only one file that I need to worry about:
/sbin/sh. If I changed root's shell to my preferred shell, /bin/ksh,
not only do I have to worry about /bin/ksh, but I also have to worry
about (on this Solaris 7 machine) libsocket.so.1, libnsl.so.1, libc.so.1,
libdl.so.1, and libmp.so.2. I.e., 6 files have to be present and
corruption free, rather than 1, so changing root's shell in this case
is 6 times as risky.
Given that it would be me trying to boot from CD at 02:00 if thiings
went bad and one of those files got corrupted, I find that increased
risk unnecessary and undesirable!
> either are pretty small. I wouldnt choose a shell, root or otherwise,
I agree that the chances of any of these files being damaged in some
way is small, but the risks are 6 times greater if I switched root's
shell to /bin/ksh. So, I leave root's shell as /sbin/sh, and automatically
invoke /bin/ksh in root's .profile after doing some checks. Why
introduce unecessary risk?
> based on this criteria. Would you Rich?
I agree with you: /sbin/sh is a pain to use interactively, but I
think that my method gives you the best of both worlds: you get a
decent, feature rich shell, but there's *no* additional risk (or
work, once the .profile has been set up) should your shell of choice
become broken.
Tim Howe
> >... Assuming that none of the required libraries are missing or corrupt.
> >If any are, then you will not be booting in single user mode (or at least,
> >logging in so that you can fix things)!
>
> True, however, the likelihood of a deleted or corrupted library is
> about the same as a deleted or corrupted shell. The chances of
> either are pretty small. I wouldnt choose a shell, root or otherwise,
> based on this criteria. Would you Rich?
Heh. I am amused that this thread somehow resurrects itself every
single week.
Regarding your statement, though, I have at least twice done silly
things like accidentally removing, um, heh, libc.so... =) I'd much
rather fix it by going into single user mode than hauling out my
rescue CD. Slightly less humiliation that way...
--
Tim Howe
* I won't speak for Sun if they promise not to speak for me. *
Thomas Dehn
> > about the same as a deleted or corrupted shell. The chances of
>
> is /sbin/sh, there is one, and only one file that I need to worry about:
> /sbin/sh. If I changed root's shell to my preferred shell, /bin/ksh,
> not only do I have to worry about /bin/ksh, but I also have to worry
> about (on this Solaris 7 machine) libsocket.so.1, libnsl.so.1, libc.so.1,
> libdl.so.1, and libmp.so.2. I.e., 6 files have to be present and
> corruption free, rather than 1, so changing root's shell in this case
> is 6 times as risky.
It is not only file corruption which might make a dynamically linked shell
unusable. /sbin is on the root partition, whereas
/usr/lib might be on a separate /usr partition, or even on a different
disk than /. /sbin/sh is thus less vulnerable to file system problems
than the dynamically linked shells.
Thomas
Russell J. LeBar
and libdl.so.1 as dependencies. I thought it was supposed to be a standalone
app? SPARC Solaris 7 patched to 11/99, the recommended May 1st cluster, and
the latest LibC and LibCx patches. Is /usr/sbin/sh a hard link to
/us/bin/sh? I cannot even 'find' /usr/sbin/sh!
As far as risk go, I think you are over simplifying. For example, in theory
larger files should be more likely to become corrupt. But on the other hand,
one could argue that a sector going bad is an independent event which would
probably (no pun intended) result in less than 6 times the risk.
But if one file is all you care about (see above about file size) then why
not statically compile bash or tcsh? The truth is Sun is 1) maintaining
backwards compatibility by sticking with sh (a weak argument) and 2)
screwing admins over by not making e.g. bash the default shell.
"Rich Teer" <ri...@rite-group.com> wrote in message
[...]
> If I changed root's shell to my preferred shell, /bin/ksh,
> not only do I have to worry about /bin/ksh, but I also have to worry
> about (on this Solaris 7 machine) libsocket.so.1, libnsl.so.1, libc.so.1,
> libdl.so.1, and libmp.so.2. I.e., 6 files have to be present and
> corruption free, rather than 1, so changing root's shell in this case
> is 6 times as risky.
[...]
Russ Allbery
> I think it is a perfectly reasonable call regardign root's shell. It's
> simple. If you leave root's shell alone, you only have to worry about
> that one file. If you change it, you have to worry about the new shell
> executable and all of the libraries that it calls. Why take the extra
> risk simply because you are too lazy to start your shell of choice after
> becoming root?
Because I become root dozens of times a day and I've yet to have a
corrupted library on local disk on 400+ Solaris servers in the past three
years. After taking one look at that cost/benefit ratio, it saves me far
more time to have a decent root shell than to leave the almost unusable
default even though I'm only saving the time of typing a single command
each time I become root.
Russ Allbery
> It is not only file corruption which might make a dynamically linked
> shell unusable. /sbin is on the root partition, whereas /usr/lib might
> be on a separate /usr partition,
It might be, but anyone who set their system up that way didn't do a very
good job of partitioning their system in my opinion. But the issue of
system overpartitioning is a completely different rant.
Russ Allbery
> Am I missing something? I ran ldd on /bin/sh and got libgen.so.1,
> libc.so.1, and libdl.so.1 as dependencies. I thought it was supposed to
> be a standalone app? SPARC Solaris 7 patched to 11/99, the recommended
> May 1st cluster, and the latest LibC and LibCx patches. Is /usr/sbin/sh
> a hard link to /us/bin/sh? I cannot even 'find' /usr/sbin/sh!
It's /sbin/sh. And it's statically linked.
windlord:~> ldd /sbin/sh
ldd: /sbin/sh: file is not a dynamic executable or shared object
Russ Allbery
> If you or your admin team have this sort of problem it would be a valid
> reason for leaving the root shell alone or, as Russell LeBar pointed
> out, compiling a static tcsh|bash|whatever.
Unfortunately, you probably can't compile a static version of any shell
that does ~username resolution on Solaris due to the damn nsswitch.conf
junk that there appears to be no way to disable or turn off without
providing your own getpwnam implementation. Long-time pet peeve of mine,
given that most of the systems I care about just have a static local
passwd file (servers rarely need more than that). It also prevents a
static build of things like tripwire unless you disable UID to username
resolution. Bleh.
(I could be missing some nice trick to get around this, and would be
grateful if there is one.)
Ideally, what you really want is the default root shell to be one thing
when the system is in multiuser mode and something else when you boot
single-user. In single-user, I still wouldn't want the default /sbin/sh;
what I'd want instead is sash (a shell with a whole bunch of commonly used
shell utilities built in to the statically linked shell so that you can do
non-trivial work on the system without using anything other than shell
builtins -- great for fixing severely broken systems).
I've thought about hacking that up using sash as the root shell and a
.profile of some sort to automatically exec tcsh if the system is
multiuser, but it never got high enough on my priority list to figure out.
Russ Allbery
>> It might be, but anyone who set their system up that way didn't do a
>> very good job of partitioning their system in my opinion. But the
>> issue of system overpartitioning is a completely different rant.
> It all depends on the disk sizes and preferred install paths involved.
No, honestly, it really doesn't. Unless you're attempting to put /usr on
a network file system, which I think is a horrible idea (hard drives
aren't that expensive), there really isn't any reason not to have /usr on
the same partition as / and quite a few reasons to do so. Now putting
things like /home and /var/spool and so forth on separate partitions are
often extremely good ideas. But nothing in /usr changes much in the
normal operating of the system or should be writeable by your users, which
is exactly the characteristics of /. The only thing that putting /usr on
a separate partition does is cause you to frequently run out of disk space
in / or in /usr when installing software or making system modifications,
and then be unable to fix it.
> There is nothing that says that /usr has (or even should) to be on the /
> partition/disk.
There's nothing that says that any directory has to be on the same
partition as the directory above it, but making every directory on your
system a separate partition is obviously stupid.
> As a matter of fact, I'm sure that there are many references that say
> exactly the opposite.
They're wrong. There's absolutely nothing that requires / and /usr to be
on different partitions. I'd be surprised if you could actually come up
with a reference that says that.
There certainly are references that advise you to do that. It's bad
advice, and I strongly recommend against following it, having been bitten
by overpartitioned systems enough times myself to have learned my lesson.
Overpartitioning your system destroys your flexibility. It should not be
done without a good reason. Preventing logs or user files from filling
critical system partitions are often good reasons, but neither should be
in /usr in the first place.
I use a single partition for servers except for /tmp (which is normally
tmpfs) and except for servers like mail servers or file servers where the
mail spool (and often the mail queue) or the file space obviously get
their own partitions. I control the size of logs using software rather
than letting them fill a partition; too much software still fails to work
properly when its log partition fills to have partitioning actually be a
solution to that problem. There's no substitute for using software that
allows you to properly cap log volume so that the partition will never
fill.
For user machines with untrusted users, I'd make /var/tmp and /tmp
separate from /, /home (or /export/home) separate from /, and usually
/var/spool separate from / (which catches both mail and print jobs).
Everything else can generally be on / unless there are special
considerations, and doing things that way gives you plenty of free disk
space to apply patches, install software, and the like without having to
make symlinks into some other partition with free space.
Whew. Warned you that this was its own rant. :)
Russ Allbery
> If root's .profile runs the shell of your choice after making some
> checks, you get to use a decent shell, risk free.
That's also a valid solution to the problem. Changing root's shell works
fine for me and has never caused me even a moment of problems, so I never
bothered figuring out the best way of changing shells automatically in
.profile.
Roger Marquis
>> simple. If you leave root's shell alone, you only have to worry about
>> that one file. If you change it, you have to worry about the new shell
>> executable and all of the libraries that it calls. Why take the extra
>> risk simply because you are too lazy to start your shell of choice after
>> becoming root?
>
>Because I become root dozens of times a day and I've yet to have a
>corrupted library on local disk on 400+ Solaris servers in the past three
>years.
My experience has been similar to Russ' i.e., never had a bad or
missing library under /usr/lib, going on 14 years now. I've never
seen any of the co-admins I've worked with have this problem either.
I'm sure it happens but rarely enough not to be a good reason for
leaving a Solaris root shell set to /sbin/sh.
If you or your admin team have this sort of problem it would be a
valid reason for leaving the root shell alone or, as Russell
LeBar pointed out, compiling a static tcsh|bash|whatever.
Any shop larger than 4 or 5 hosts should have an external CD drive
hanging around somewhere anyhow. It shouldn't take more than 15
minutes to plug it in, boot from it, and replace whatever files
were lost.
Of course none of this makes any difference to those who believe
the "never change a Solaris root shell" old wives tale.
>After taking one look at that cost/benefit ratio, it saves me far
>more time to have a decent root shell than to leave the almost unusable
>default even though I'm only saving the time of typing a single command
>each time I become root.
Ditto.
Fredrich P. Maney
: Thomas Dehn <thomas...@myokay.net> writes:
:> It is not only file corruption which might make a dynamically linked
:> shell unusable. /sbin is on the root partition, whereas /usr/lib might
:> be on a separate /usr partition,
: It might be, but anyone who set their system up that way didn't do a very
: good job of partitioning their system in my opinion. But the issue of
: system overpartitioning is a completely different rant.
It all depends on the disk sizes and preferred install paths involved.
There is nothing that says that /usr has (or even should) to be on the /
partition/disk. As a matter of fact, I'm sure that there are many references
that say exactly the opposite.
fpsm
Rich Teer
> My experience has been similar to Russ' i.e., never had a bad or
> missing library under /usr/lib, going on 14 years now. I've never
> seen any of the co-admins I've worked with have this problem either.
> I'm sure it happens but rarely enough not to be a good reason for
> leaving a Solaris root shell set to /sbin/sh.
I've never had a disk crash, either, but I still make regular back ups...
> >After taking one look at that cost/benefit ratio, it saves me far
> >more time to have a decent root shell than to leave the almost unusable
> >default even though I'm only saving the time of typing a single command
> >each time I become root.
Yes, but you can arrange to have a decent shell as root without any
effort and no extra risk - so why not do it that way?
Rich Teer
> Am I missing something? I ran ldd on /bin/sh and got libgen.so.1, libc.so.1,
Yeah - we're talking about /sbin/sh, not /bin/sh...
> As far as risk go, I think you are over simplifying. For example, in theory
> larger files should be more likely to become corrupt. But on the other hand,
> one could argue that a sector going bad is an independent event which would
> probably (no pun intended) result in less than 6 times the risk.
Eh? /sbin/sh is around 256k on my machine; the combined size of /bin/sh
and all the libraries is about 1.5 MB (/usr/lib/libc.so.1 itself exceeds
1 MB in size), so I don't know what point you're trying ot make.
> But if one file is all you care about (see above about file size) then why
> not statically compile bash or tcsh? The truth is Sun is 1) maintaining
Um, because I don't like bash or tcsh. ksh does all I want.
> backwards compatibility by sticking with sh (a weak argument) and 2)
> screwing admins over by not making e.g. bash the default shell.
bash doesn't even come with Solaris (well, OK it now comes with Solaris 8 on
the Software Supplement CD), so why would it be the default. Also, why
would Sun make a shell they don't support the default one for root? That
wouldn't be very responsible, would it?
Rich Teer
> Because I become root dozens of times a day and I've yet to have a
> corrupted library on local disk on 400+ Solaris servers in the past three
> years. After taking one look at that cost/benefit ratio, it saves me far
> more time to have a decent root shell than to leave the almost unusable
> default even though I'm only saving the time of typing a single command
> each time I become root.
I too, have never had a corrupted library. But why have unneccessary (although
admittedly small) risk. If root's .profile runs the shell of your choice
after making some checks, you get to use a decent shell, risk free. That's
gotta be a win!
Fredrich P. Maney
: Am I missing something? I ran ldd on /bin/sh and got libgen.so.1, libc.so.1,
: app? SPARC Solaris 7 patched to 11/99, the recommended May 1st cluster, and
: the latest LibC and LibCx patches. Is /usr/sbin/sh a hard link to
: /us/bin/sh? I cannot even 'find' /usr/sbin/sh!
It's /sbin/sh not /bin/sh. And it is statically linked.
[deletia]
Richard L. Hamilton
"Russell J. LeBar" <ar...@email.sn.com> writes:
> Am I missing something? I ran ldd on /bin/sh and got libgen.so.1, libc.so.1,
> and libdl.so.1 as dependencies. I thought it was supposed to be a standalone
> app? SPARC Solaris 7 patched to 11/99, the recommended May 1st cluster, and
> the latest LibC and LibCx patches. Is /usr/sbin/sh a hard link to
> /us/bin/sh? I cannot even 'find' /usr/sbin/sh!
You are missing something:
$ ldd /sbin/sh
ldd: /sbin/sh: file is not a dynamic executable or shared object
Note /sbin/sh, _not_ /usr/sbin/sh (no such thing) or /bin/sh or
/usr/bin/sh (/bin on Suns being a symlink to /usr/bin).
> As far as risk go, I think you are over simplifying. For example, in theory
> larger files should be more likely to become corrupt. But on the other hand,
> one could argue that a sector going bad is an independent event which would
> probably (no pun intended) result in less than 6 times the risk.
Not that independent. For a file to be good, all the data blocks have
to be good, and they're dependent on the inode and indirect blocks, as
well as the filesystem structure (/usr can be a separate filesystem).
And depending on whether the damage is due to hardware, software, or
undetected memory errors (background radiation, typically), the risk
that various blocks are at may not be uniform; especially in the
latter two cases, I'd expect commonly used shared libraries to be
at greater risk of a read accidentally becoming a write.
I _have_ seen a case where a shared library got just slightly messed
up (no disk error though) but everything else on the system was ok.
It was dumb luck that it hit a part of the library that had stuff in
it that wasn't needed to boot, and sheer stubbornness that after
comparing checksums on the kernel and relevant executables, I finally
did the same to all applicable shared libraries, and found it. Naturally
it was libc, the one shared library that everything that bothers with
shared libraries at all uses.
I grant that is was a one in a thousand machine-years sort of thing, i.e.
was just once a long time ago (and on SunOS 4.x, but IMO it wasn't more
vulnerable than Solaris 2.x) but just as with large disk arrays one should
realize that MTBF over a large number of disks means you can expect a few
to fail every year, so over a large site with lots of machines (or a
single machine where minimum possible down time was paramount), I wouldn't
regard even a small risk as acceptable for the feeble convenience of not
having to invoke my fave shell explicitly.
> But if one file is all you care about (see above about file size) then why
> not statically compile bash or tcsh? The truth is Sun is 1) maintaining
> backwards compatibility by sticking with sh (a weak argument) and 2)
> screwing admins over by not making e.g. bash the default shell.
Is bash fully POSIX compliant? IMO, in the long run they ought to
move towards a statically linked POSIX compliant shell for root.
I'd personally prefer a true ksh-based POSIX shell rather than
a bash-based one (I've been burned by bash before, although it may
well have been a way older version). Note that although perhaps
not OSD compliant, one can get true ksh source nowadays, at least for
non-commercial purposes. That being the case, if I were inclined to
give a darn what root's default shell is (which I shouldn't, 'cause
I shouldn't be spending too much time in an interactive root shell),
I'd be tempted to try and build a static ksh93. I'm not sure though
how much persuasion it would take to get gcc to give me a totally
static compilation, but maybe I could get down to just stuff in
/etc/lib, which would at least be a slight improvement. But I'd
_still_ only stick such a nonstandard undocumented hack on my
own workstation or on my home boxes, _never_ on production servers.
It's really about the discipline to Do The Right Thing even if it
sucks IMO, 'cause if you get run over one fine morning, someone else will
have to pick up what you left them.
If you were to say that you'd like to see Sun provide static versions
of a couple more shells, I could easily enough agree with you on that,
for whatever negligible influence my opinion may contribute.
BTW, even between sh and ksh, where backwards compatibility was very
much a design consideration (and AFAIK the two actually share much
source anymore), I've heard of instances of real-world nontrivial
compatibility problems (but that was a long time ago, so it may
either have gotten better, or in any event will be something that
I'd be hard pressed to provide more details on).
> "Rich Teer" <ri...@rite-group.com> wrote in message
> [...]
>> If I changed root's shell to my preferred shell, /bin/ksh,
>> not only do I have to worry about /bin/ksh, but I also have to worry
>> about (on this Solaris 7 machine) libsocket.so.1, libnsl.so.1, libc.so.1,
>> libdl.so.1, and libmp.so.2. I.e., 6 files have to be present and
>> corruption free, rather than 1, so changing root's shell in this case
>> is 6 times as risky.
> [...]
>
>
--
ftp> get |fortune
377 I/O error: smart remark generator failed
Bogonics: the primary language inside the Beltway
mailto:rlh...@mindwarp.smart.net http://www.smart.net/~rlhamil
Fredrich P. Maney
:>> It might be, but anyone who set their system up that way didn't do a
:>> very good job of partitioning their system in my opinion. But the
:>> issue of system overpartitioning is a completely different rant.
:> It all depends on the disk sizes and preferred install paths involved.
: No, honestly, it really doesn't. Unless you're attempting to put /usr on
: a network file system, which I think is a horrible idea (hard drives
: aren't that expensive), there really isn't any reason not to have /usr on
: the same partition as / and quite a few reasons to do so. Now putting
: things like /home and /var/spool and so forth on separate partitions are
: often extremely good ideas. But nothing in /usr changes much in the
: normal operating of the system or should be writeable by your users, which
: is exactly the characteristics of /. The only thing that putting /usr on
: a separate partition does is cause you to frequently run out of disk space
: in / or in /usr when installing software or making system modifications,
: and then be unable to fix it.
Yes it does. If you are working on machines (like I have, and continue
to do) that only have a 525mb internal boot disk (lots and lots and lots
of little machines all over the damn country) with all of their data on
an external disk, it does matter. There are *many* instances there where
you can run into the problem of there simply not being enough room on
the boot disk for /usr, /var, /etc, and /opt. And with that being the
case, either /usr or /opt (or both) has to go somewhere else.
:> There is nothing that says that /usr has (or even should) to be on the /
:> partition/disk.
: There's nothing that says that any directory has to be on the same
: partition as the directory above it, but making every directory on your
: system a separate partition is obviously stupid.
And who has suggested that you do such a thing? Certainly not I.
:> As a matter of fact, I'm sure that there are many references that say
:> exactly the opposite.
: They're wrong. There's absolutely nothing that requires / and /usr to be
: on different partitions. I'd be surprised if you could actually come up
: with a reference that says that.
: There certainly are references that advise you to do that. It's bad
: advice, and I strongly recommend against following it, having been bitten
: by overpartitioned systems enough times myself to have learned my lesson.
: Overpartitioning your system destroys your flexibility. It should not be
: done without a good reason. Preventing logs or user files from filling
: critical system partitions are often good reasons, but neither should be
: in /usr in the first place.
: I use a single partition for servers except for /tmp (which is normally
: tmpfs) and except for servers like mail servers or file servers where the
: mail spool (and often the mail queue) or the file space obviously get
: their own partitions. I control the size of logs using software rather
: than letting them fill a partition; too much software still fails to work
: properly when its log partition fills to have partitioning actually be a
: solution to that problem. There's no substitute for using software that
: allows you to properly cap log volume so that the partition will never
: fill.
And that is a highly risky thing to do. In the environments I work in
(both the large systems and the small systems), maximum uptime and
reliability are the guiding force behind system design. I simply *can
not* have a system go down because / filled up *for any reason*. I put
/var and /tmp separate from / to protect it from that and leave everything
else that I can in one partition (besides /home and /data). However
there are times when there simply isn't enough space to do that.
: For user machines with untrusted users, I'd make /var/tmp and /tmp
: separate from /, /home (or /export/home) separate from /, and usually
: /var/spool separate from / (which catches both mail and print jobs).
: Everything else can generally be on / unless there are special
: considerations, and doing things that way gives you plenty of free disk
: space to apply patches, install software, and the like without having to
: make symlinks into some other partition with free space.
Understood, we must work in completely different environments though,
because all of my machines are "user machines" and every user is "untrusted".
: Whew. Warned you that this was its own rant. :)
Russell J. LeBar
"Richard L. Hamilton" <rlh...@smart.net> wrote in message
news:8gj9fc$7ne$7...@news.smart.net...
> In article <#FuDarcx$GA.326@cpmsnbbsa07>,
> But I'd
> _still_ only stick such a nonstandard undocumented hack on my
> own workstation or on my home boxes, _never_ on production servers.
> It's really about the discipline to Do The Right Thing even if it
> sucks IMO, 'cause if you get run over one fine morning, someone else will
> have to pick up what you left them.
I won't argue with that one, espcially considering how easy it is to alias
e.g. SU to su - root -c <your favorite shell>.
> If you were to say that you'd like to see Sun provide static versions
> of a couple more shells, I could easily enough agree with you on that,
> for whatever negligible influence my opinion may contribute.
As Windows NT, Windows 2000, and Linux distributions continue to gain in
popularity, the failure of other UNIX vendors to improve useability become
more and more obvious. Why is it that *finally* in Solaris 8 it ships with
e.g. gzip, perl, tcsh, and bash?
> BTW, even between sh and ksh, where backwards compatibility was very
> much a design consideration (and AFAIK the two actually share much
> source anymore), I've heard of instances of real-world nontrivial
> compatibility problems (but that was a long time ago, so it may
> either have gotten better, or in any event will be something that
> I'd be hard pressed to provide more details on).
That would not suprise me. But any scripts written should do the #! thing
anyway so altering root's shell from a compatibility standpoint does not
seem like a big issue to me (I am talking about the vendors changing the
default shell, not admins later on). I do not think anyone is advocating
removal of the other shells.
If one agrees we shouls spend as little time logged in as root, then I'd
like to point out that things like tab completion, command line editing, and
an easy method to cycle through previous commands should greatly help in
getting that need-to-be root task done! ;-)
--
Russ LeBar
UNIX System Administrator
Enterprise Rent-A-Car
Fredrich P. Maney
[deletia]
: If one agrees we shouls spend as little time logged in as root, then I'd
: like to point out that things like tab completion, command line editing, and
: an easy method to cycle through previous commands should greatly help in
: getting that need-to-be root task done! ;-)
Those types of functions though just lead to making the admin comfortable
as root (as well as facilitating accidents). Since the whole point is
that you should be spending as little time as possible as root (ideally
you would use different specific priviledged accounts for different
subsystems so that you could only muck up one subsystem at a time), I
don't think that adding any of these functions is a valid reason for
changing root's default shell. That is, plain and simple, a hack (and an
unsupported one at that). If you simply *must* have these nice functions
to make you feel all warm and fuzzy and comfortable as root, then you
are spending too much time as root.
Keith Thompson
> Rich Teer <ri...@rite-group.com> writes:
>
> > If root's .profile runs the shell of your choice after making some
> > checks, you get to use a decent shell, risk free.
>
> fine for me and has never caused me even a moment of problems, so I never
> bothered figuring out the best way of changing shells automatically in
> .profile.
I use another solution on my system at home (a SparcStation 2 running
SunOS 4.1.3). I leave root's login shell strictly alone, but I add a
"roott" entry to /etc/passwd. The "roott" account has a uid of 0 (so
it's effectively the same account as root), but its login shell is
/bin/tcsh, which happens to be my preferred interactive shell.
This has worked pretty well for me so far. On the relatively rare
occasions when I need a root shell, I get tab completion, aliases, and
all that good stuff. If the system is clobbered to the point where
/bin/tcsh doesn't work, I can revert to the standard root account and
muddle through with /bin/sh.
I suspect there might be some reason this is a horrible idea, but I
can't think of one.
--
Keith Thompson (The_Other_Keith) k...@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.
Fredrich P. Maney
[deletia]
: I use another solution on my system at home (a SparcStation 2 running
: SunOS 4.1.3). I leave root's login shell strictly alone, but I add a
: "roott" entry to /etc/passwd. The "roott" account has a uid of 0 (so
: it's effectively the same account as root), but its login shell is
: /bin/tcsh, which happens to be my preferred interactive shell.
: This has worked pretty well for me so far. On the relatively rare
: occasions when I need a root shell, I get tab completion, aliases, and
: all that good stuff. If the system is clobbered to the point where
: /bin/tcsh doesn't work, I can revert to the standard root account and
: muddle through with /bin/sh.
: I suspect there might be some reason this is a horrible idea, but I
: can't think of one.
This one has been mentioned before. The reason not to do it is security.
- You can't separate the logging between the two accounts (since they have
the same uid) so if you get hacked you don't know through which account.
- You have to maintain root security measures on two accounts instead of
just one.
- You are doubling you chances of a root level account hack.
And I'm sure there are several other reasons not to do this since this is
just off the top of my head and it is ridicuously early to be up on a
Saturday morning.
Rob McMahon
> : I use a single partition for servers except for /tmp (which is normally
> : tmpfs) and except for servers like mail servers or file servers where the
> : mail spool (and often the mail queue) or the file space obviously get
> : their own partitions...
>
> And that is a highly risky thing to do. In the environments I work in (both
> the large systems and the small systems), maximum uptime and reliability are
> the guiding force behind system design. I simply *can not* have a system go
> down because / filled up *for any reason*. I put /var and /tmp separate from
> / to protect it from that and leave everything else that I can in one
> partition (besides /home and /data). However there are times when there
> simply isn't enough space to do that.
It's not just a matter of / filling up. A mostly read-only filesystem is much
less likely to end up corrupted than a write intensive one like /var. Which
would you rather see corrupted, /var or / ? Plus /var can be mounted nosuid.
Rob
--
INET: Rob.McMahon near warwick.ac.uk PHONE: +44 24 7652 3037
Rob McMahon, IT Services, Warwick University, Coventry, CV4 7AL, England
Russ Allbery
> Yes it does. If you are working on machines (like I have, and continue
> to do) that only have a 525mb internal boot disk (lots and lots and lots
> of little machines all over the damn country) with all of their data on
> an external disk, it does matter.
The Solaris installation I use only takes a total of 120MB for servers,
but yeah, if you need all the extra junk and you have a really small disk,
you may need to split things more than you'd ideally want to do. But I'd
rather buy large disks; you can't even find disks smaller than about 4GB
these days.
I see your point, but even the machines we have that are six years old
have larger internal disks than that. We just don't have that many really
old systems around.
>> I control the size of logs using software rather than letting them fill
>> a partition; too much software still fails to work properly when its
>> log partition fills to have partitioning actually be a solution to that
>> problem. There's no substitute for using software that allows you to
>> properly cap log volume so that the partition will never fill.
> And that is a highly risky thing to do.
No, it's not, not if the software works. Again, if the log partition
fills, the software tends to not work anyway, so there's actually little
difference.
> In the environments I work in (both the large systems and the small
> systems), maximum uptime and reliability are the guiding force behind
> system design. I simply *can not* have a system go down because / filled
> up *for any reason*.
You're assuming that / filling will take the system down. In my
experience, / filling is a fairly minor experience. I've had / be filled
for weeks without even noticing, because the service provided by the
system was still running fine. Why? Because the areas where it was
actually writing data were on a separate partition (and this I agree
with).
/ and /usr are both static operating system data and having them fill
rarely matters if you've planned your system layout properly.
hume.sp...@bofh.halifax.ns.ca
> / and /usr are both static operating system data and having them fill
> rarely matters if you've planned your system layout properly.
Well, / isn't totally static. Sometimes users want to change their
passwords. :)
Any opinions on mounting /usr read-only? In fact, I've spoken with some
people who think burning out /usr to a CD is a good idea...
--
Brandon Hume - hume -> BOFH.Halifax.NS.Ca, http://WWW.BOFH.Halifax.NS.Ca/
-> Solaris Snob and general NOCMonkey
Andrew Gabriel
hume.sp...@bofh.halifax.ns.ca writes:
> Any opinions on mounting /usr read-only? In fact, I've spoken with some
> people who think burning out /usr to a CD is a good idea...
/usr is intended to be able to be mounted read-only.
I always do so.
Likewise /opt (although there you are at the mercy of third-party
packagers getting their products layed out correctly on the
different filesystems, but when they get this wrong, I fix it
on my system).
--
Andrew Gabriel
Andy M
hume.sp...@bofh.halifax.ns.ca wrote:
> Russ Allbery <r...@stanford.edu> wrote:
> > / and /usr are both static operating system data and having
> > them fill rarely matters if you've planned your system layout
> > properly.
>
> Well, / isn't totally static. Sometimes users want to change their
> passwords. :)
Installing patches requires a little space on /.
> Any opinions on mounting /usr read-only? In fact, I've spoken with
> some people who think burning out /usr to a CD is a good idea...
Well, except for quarterly patch updates ($1/per CD) and taking up
the CD slot, I don't see where it would kill you. CD access *is* a
little slower tho...
--
-Andy M
http://synecdoche.net/~andy
Sent via Deja.com http://www.deja.com/
Before you buy.
Raymond N Shwake
>In article <8h3360$sgr$1...@news.dal.ca>,
> hume.sp...@bofh.halifax.ns.ca writes:
>> Any opinions on mounting /usr read-only? In fact, I've spoken with some
>> people who think burning out /usr to a CD is a good idea...
>/usr is intended to be able to be mounted read-only.
>I always do so.
I assume you don't expect to add or update software very often.
Much of that software wants to go into /usr, so you'd have to unmount it
(assuming it's not "busy" supporting active processes), remount it read/write,
make the changes, then unmount and remount read-only. I'd rather just set
permissions appropriately and be support /usr as a potentially dynamic
filesystem.
Andrew Gabriel
rsh...@rsxtech.atww.org (Raymond N Shwake) writes:
>and...@cucumber.demon.co.uk (Andrew Gabriel) writes:
>
>>In article <8h3360$sgr$1...@news.dal.ca>,
>> hume.sp...@bofh.halifax.ns.ca writes:
>>> Any opinions on mounting /usr read-only? In fact, I've spoken with some
>>> people who think burning out /usr to a CD is a good idea...
>
>>/usr is intended to be able to be mounted read-only.
>>I always do so.
>
> I assume you don't expect to add or update software very often.
Not the software in /usr. Only when applying patches or upgrading
the operating system (for which you must remove the 'ro' flag from
/etc/vfstab).
>Much of that software wants to go into /usr, so you'd have to unmount it
>(assuming it's not "busy" supporting active processes), remount it read/write,
>make the changes, then unmount and remount read-only. I'd rather just set
>permissions appropriately and be support /usr as a potentially dynamic
>filesystem.
No, you only need to... mount -o remount,rw /usr
I don't think there would be any chance of getting /usr unmounted.
You can't go back to ro though - that just happens next time system
gets booted.
--
Andrew Gabriel
Consultant Software Engineer