Re: itp: static bins / resolving static debian issues
Hi folks:
I'm rather new to this list, so kindly forgive me if it shows.
First a brief comment -- I hadn't heard of sash until it was mentioned
here. I can't imagine that many Debian users reading the description of
every optional and extra package available looking for ones they might
have a need for.... not to mention the description for sash doesn't
explicitly point out its usefulness as a recovery shell.
> Date: Fri, 20 Aug 1999 19:39:40 -0400
> From: Michael Stone <mstone@debian.org>
>
> Nope. I've never been opposed to a local admin making /bin/sash his
> default root shell--that's the way I do things here. But that's another
> local configuration issue and shouldn't be a general default.
I tend to disagree, and here's why:
What root's shell is, is the local configuration issue. Debian should
provide a sensible default. More on that later....
Likewise, what users have superuser privileges, is a local configuration
issue. In my (admittedly limited) experience, and from what I have read
from various security mailing lists and newsgroups, having multiple UID
0 users can be a security hazard; it requires extra administrative
effort to maintain the extra account (ie make sure to change the
password along with the root password, keep track of access to this
account as well, etc).
Basically, it introduces an additional point of failure in Debian's
security structure. This should not be taken lightly. In any case, it
strikes me that a second superuser account should be the non-default
"local configuration issue" that admins have to settle.
On the contrary, setting sash as root's shell is less intrusive: it
gives advantages in reliability.
The costs are:
memory
You'll be interested to know that the static sash uses less memory
than the unshared segment of bash's memory. On my computer, at least:
PID TTY MAJFLT MINFLT TRS DRS SIZE SWAP RSS SHRD LIB DT
COMMAND
1242 p6 21 20 84 44 128 0 128 76 0 13
sash
1238 p6 250 80 308 788 1096 0 1096 852 0 61
bash
disk space
If sash is already installed, then....
performance
Given the speed of todays computers, the relatively simple tasks that
will be performed within sash, performance is a non-issue.
convenience
No tab-completion, no saved history. This is a tradeoff. It seems
requiring a root user to type "bash" or "exec bash" to get these
features is a fair convenience for what sash provides. Perhaps there
is some way for sash to automatically (offer to) try to exec bash
before giving you a prompt, or remind you that you're not in bash.
compatibility
It has already been established that what the root shell is does not
meaningfully alter how other programs, scripts, etc are run, so this
is a non-issue.
It strikes me that given the reliability advantage for the people
(however few) who may find sash useful, against the inconvenience, sash
should be the default root shell where it is installed.
In addition, one common concept that comes up periodically in security,
and applies here, is failsafe defaults. That is, if a person does
nothing to modify the behavior, it does what is safest, most reliable,
etc. It seems that, if sash is installed, it should be made as the
default root shell.
This is also a good reason why, IMHO, sash should be selected by default
for install (ie its priority should be standard or important). This is
in addition to the other technical and policy reasons mentioned
elsewhere in the thread. Note that some users lacking in clue may find
it useful to have, and considering the costs and benefits, it strikes me
that we should give it to them. There is nothing to be gained by making
life difficult for such people.
Here is what I suggest:
currently sash is priority optional. When installed, it asks you if you
want to change root's login shell to sash. Default is "no".
Change this to:
set the priority of sash to standard or important. On install, ask if
you want to make this the default root shell. Default to "yes". Say
something like "In certain cases where something has gone wrong with the
system, setting this can allow you to recover your system without
needing to reboot", so the user knows why it may be a good idea to say
yes.
Then, we can deal with standardizing a larger static toolkit for
Debian....
> > -- recover from an administrator error, such as someone mis-using
> > dpkg or "rm -rf *" in a way that leaves the dynamics broken, and
> > doing so without disturbing your clients who are connecting to
> > servers on your box (servers are linked and loaded already)
>
> And I said to squirrel a backup root partition on a seperate disk.
> You've already argued that a couple of dozen megs are negligable, so the
> space is well worth protection against library corruption, user error,
> hardware failure, etc. How do your static bins help if your hard disk
> dies completely? The backup root'll still be there... Your solution
> solves a _strict subset_ of the problems that a redundant solution will
> solve, and the only argument you've provided against it is the (false)
> argument that you need to reboot and the (personal problem) that you
> prefer static binaries. If you want a package of optional static
> binaries and you can convince someone to do the work, fine--I don't
> care. But until you can demonstrate how you _can't_ recover without that
> package, don't expect a lot of support for making it the default.
Spare root disks are fine for production servers where uptime is
crucial. However, for a generic user system or small server, the admins
don't always have the time to set up and maintain such a system (if
there were a package that did it for us, though....).
A set of static bins, on the contrary, requires minimal effort (there by
default...., or at worst, select package, select "Install") and has
largely the same result (depending on how catastrophic the failure is --
how does backup root help if the machine gets unplugged, or the power
supply goes....).
Of course I've been in such a situation, but IMHO the philosophy should
be, if it helps even one user to recover cleanly where that user didn't
have the presence of mind (or the spare time) to create a spare root,
then it's worth including the respective tools.
> > -- fix a system for someone who isn't as aware of these issues as
> > i am, and didn't know to install sash
>
> Uh huh. The inexperienced beginner is going to whip out his static
> binaries, wave his magic wand, and fix a system that he doesn't
> understand in the first place. Pull the other one...
Or if someone with a broken system asks for your help, says "I need to
save what I have here before rebooting" for whatever reason. Or
mentioned as part of a "Recovering Debian" piece of documentation, so
anyone who reads it will know how to use the static toolkit to make the
system magically work again.
> > -- someone can fix a system after it fails, if they never knew about
> > sash and never thought about statics or live recovery, because it
> [snip]
>
> So the person never gave a thought to reliability, didn't take the time
> to set up a redundant environment (that backup root's still going to do
> wonders here) and is running a server that _can't possibly be rebooted_?
Again, I don't think we should penalize the folks who didn't have the
time or the presence of mind to take precautions for every contingency.
Nor should we penalize the folks who assume that the static binaries are
there because it looks like UNIX (or even Linux), and on the previous
version of UNIX (Linux) that the admin used, they were there.
Of course there are a number of convenience issues involved. For
instance, the time involved in rebooting a computer (maybe via the reset
switch, depending on whether we have a shell and whether
shutdown/halt/reboot work....), booting via floppy (or spare root),
fsck'ing if necessary, and then rebooting again after we're done.
In addition, the convenience of being able to perform emergency admin
stuff remotely (admittedly this class of uses is mostly confined to more
experienced admins who should know to have some redundancy installed and
available, but see the above statements about admins who lack in clue).
> Mike Stone
bye then,
algis r
--
Algis Rudys Rice University
arudys@rice.edu Will Rice College, Class of 2000
Kindly CC list replies to me.
Reply to: