Re: Serious Bug in most major Linux distros.

2002-05-31 Thread Karsten M. Self
on Tue, May 28, 2002, Petro ([EMAIL PROTECTED]) seperated the wheat
from the chaff, and gave us the following chaff...:
 On Sat, May 25, 2002 at 12:32:02AM -0700, Karsten M. Self wrote:

  The point was that the answer to your question (Is this the first...)
  is readily available from the usual place.  Your assignment is to read
  the earlier posts and either:
 
 There are over 100 links, many of them redundant, with the link you
 provided. 

...chaff...

- Formulate a previously unaddressed reason root should have a
  statically linked shell, rather than pollute the list with largely
  irrelevent dialog.
 
 There is no reason to formulate a previously unaddressed reason,

...chaff...

- Understand why the current alternative(s) are sufficient.

 They aren't. They are close, and can be made proper with a little

...chaff...

- Summarize findings to list and quietly exit the topic.
 
 Summary: Sash should be installed by default in /sbin/sash and as
 default should be the root users shell. It adds about 610k to a
 default install and has little or no downside in a properly set up
 environment. 

Oh.  Nearly salience.

Three line digression:  I'm not opposed to hearing cogent arguments.
You've not presented any.  You've whined.  You're wasting my and the
lists time.  Stop it.  Get to the point.

OK, so you've presented a conclusion without substantiation.  How about
a three minute lesson on why root's shell has been historically
statically linked:

The reason root's default shell (/sbin/sh) is statically linked is
historical.  Back when 127MB was considered a large disk /usr (and
the libraries under /usr/lib) had to be mounted from a second disk
or NFS server.  When a server boots into single-user mode it will
not mount the /usr partition breaking any dynamically linked shell.
The solution to this is simple: don't partition /usr.  Since the
advent of larger hard drives there has not been a good reason to
partition /usr.  There is also substantial risk associated with
partitioning the /usr filesystem.

http://www.roble.com/docs/sol_root_shell.html

This document goes on to discuss a number of myths about the root shell.
If you have specific countarguments, then make them.


There might be a number of reasons to advocate a particular root shell.
You haven't made them:

   - Security.
   - Recoverability / stability.
   - Tradition.
   - Standards / compliance.
   - Site preferences / standards.
   - Personal preference.

The first four seem to offer weak support at best for your position.
For a given site with multiple admins, a standard for root's shell among
the several admins is a Good Thing, as it keeps different admins from
clobbering one another (or forces them to use more substantial means to
do same).  There's no need for that shell to be a statically linked one,
however.

I'd argue that personal preference and comfort have a lot to say for the
discussion.  I *don't* run my systems as root.  I *do* almost always
have a root shell available for rootly tasks.  The shell I use (bash) is
powerful, script-sane, one I'm comfortable with, and (bonus) standard on
GNU/Linux.  Why force me into too-tight gloves when I'm doing tasks
where polished execution matters?

The argument that bash won't run if you can only mount your root
partition (assuming this excludes /usr) won't hunt on Debian:

$ ldd /bin/bash
libncurses.so.5 = /lib/libncurses.so.5 (0x4002)
libdl.so.2 = /lib/libdl.so.2 (0x4005e000)
libc.so.6 = /lib/libc.so.6 (0x40062000)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000)

The valid arguments for a static root shell are system recovery and for
working on a system whose integrity is compromised.  For the former, I'd
far prefer bootable rescue media (http://www.lnx-bbc.org/).  For the
latter, a statically linked shell means you don't have to worry about
the integrity of system libs, but if your cracker's replaced the
system's copy of sash, you're still fscked.  Better:  use a known good
copy from inert media (a write-protected floppy, or CDROM), if you
absolutely *must* work on the system.  Far better to shut down a
compromised box immediately, do a clean install, and clean of any uglies
lying around elsewhere.

I keep sash installed on my systems.  Mostly so that I can dig myself
out of a hole if I fsck up libs or suffer bad (but not utterly fatal)
disk problems.  I'd recommend it as a good fallback.  As a default
shell, sash isn't acceptable as it's not POSIX compliant.  It's useful
(and intended as same), but not standard.

Peace.

-- 
Karsten M. Self kmself@ix.netcom.comhttp://kmself.home.netcom.com/
 What Part of Gestalt don't you understand?
   TWikIWETHEY: Technology, free software, GNU/Linux, and a little bit
   of everything else:  http://twiki.iwethey.org/twiki/bin/view/


pgpKrmhTU2CJl.pgp
Description: PGP signature


Re: Serious Bug in most major Linux distros.

2002-05-29 Thread Rob Ransbottom
On Thu, 23 May 2002, Petro wrote:

 On Thu, May 23, 2002 at 01:04:17PM -0400, Rob Ransbottom wrote:
  On Wed, 22 May 2002, Petro wrote:
  
  Even then I ask:  You _want_ to keep your users going when your shared
  libs are flakey???
 
 I don't have users in the normal sense. I run clusters of web and
 database servers,

A distinction without difference here.

   things that are hard to keep backed up 100%. 
 I do have a few users, but they are mostly developers, and on their
 staging and dev boxes it might be necessary at some point to get in
 and recovery certain bits. 

 But it's not just about *me*, I can, because of the resources I have
 available to me in a medium sized installation (currently around 100
 servers) take a box down and replace it with another one until I
 have time to get down the colo and do things some other way. 
 
 Not everyone has this luxury. 

This is not clear to me.  I get out of this that you are scratching
at an itch which isn't yours.

  Shared libs could implement a load_all_required_functions routine.
  This would let a program getuid and act like it had static libs.
 
 This sounds more complex, and unnecessary complexity is not a good
 thing. 

Actually this would simplify things -- most problems (discounting bugs)
with libs have to do with mismatching and lacking libs.  Of course 
it is an evolutionary solution, that is appealing when broadly accepted.
I doubt much need is seen.

What problem are you having or foreseeing?  Don't waste time
on problems you don't have.  How can we help?

  I just keep a rescue partition loaded with debian-base.  This
  has lots of benefits.  And having your normal root environment is 
  nice in stressful situations.
 
 That isn't a bad idea. 

It is even better than not bad.   You may have an even smaller
rescue/boot partition that simply serves out its filesystems.

 My last cigarette was roughly 31 days, 9 hours, 3 minutes ago.

The traces of habitual patterns should vanish in a year or so.  
Then it becomes easy.  Good going, and good luck going forward.

 YHBW

YHBW?

rob Live the dream.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Serious Bug in most major Linux distros.

2002-05-28 Thread Petro
On Sat, May 25, 2002 at 12:32:02AM -0700, Karsten M. Self wrote:
 on Wed, May 22, 2002, Petro ([EMAIL PROTECTED]) wrote:
  On Wed, May 22, 2002 at 03:16:57AM -0700, Karsten M. Self wrote:
   on Tue, May 21, 2002, Petro ([EMAIL PROTECTED]) wrote:
Is this the first time someone has brought this up? 
   Puhleaze:
  There's a bunch of people here acting like they've never heard of
  the idea, and the only somewhat reasonable excuse I've heard for not
  doing it is It's a lot of work, which lead me to believe it  hadn't
  been discussed here. 
 http://www.google.com/search?q=debian+statically+linked+root+shell
  So it has been brought up before, over 2 years ago, and it's still
  wrong? 
 The point was that the answer to your question (Is this the first...)
 is readily available from the usual place.  Your assignment is to read
 the earlier posts and either:

There are over 100 links, many of them redundant, with the link you
provided. 

The vast majority of them are redundant, or do have no mention of
*why* such a bad decision was made. 

The one that does--which does happen to be the first on the list,
shows a lot of navel gazing, short sightedness, and a general
lack of will to actually listen to people who have an idea about how
reliable, robust systems can be designed that doesn't involve fancy
new widgets.

   - Formulate a previously unaddressed reason root should have a
 statically linked shell, rather than pollute the list with largely
 irrelevent dialog.

There is no reason to formulate a previously unaddressed reason,
when the previous reasons are perfectly adequate, and have not been
properly addressed. 

As to your pollute the list comment, quite frankly it is something
I, and by *the first link* on that Google query you posted, several
other working Sysadmins, think is a very vaild question.

My first post on this was as to *why* such a basic thing isn't being
done. After all, where does /sbin get it's name? Well, /bin is
binaries. /sbin is *static* binaries. Of which there are...one. 

All I asked was why. 

The answers I recieved tended to indicate a lack of previous
investigation into the subject, which caused my query as to whether
this had been discussed previously. 

   - Understand why the current alternative(s) are sufficient.

They aren't. They are close, and can be made proper with a little
work. Which describes about 80% of linux (which is better than a lot
of OSs, even other Unixes.). 

   - Summarize findings to list and quietly exit the topic.

Summary: Sash should be installed by default in /sbin/sash and as
default should be the root users shell. It adds about 610k to a
default install and has little or no downside in a properly set up
environment. 

Yes, there should be a way *not* to install it, for those who are
experienced and understand fully the ramifications of this decision. 

-- 
My last cigarette was roughly 36 days, 12 hours, 4 minutes ago.
YHBW


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Serious Bug in most major Linux distros.

2002-05-25 Thread Karsten M. Self
on Wed, May 22, 2002, Petro ([EMAIL PROTECTED]) wrote:
 On Wed, May 22, 2002 at 03:16:57AM -0700, Karsten M. Self wrote:
  on Tue, May 21, 2002, Petro ([EMAIL PROTECTED]) wrote:

...

   Is this the first time someone has brought this up? 
  Puhleaze:
 
 There's a bunch of people here acting like they've never heard of
 the idea, and the only somewhat reasonable excuse I've heard for not
 doing it is It's a lot of work, which lead me to believe it hadn't
 been discussed here. 
 
  http://www.google.com/search?q=debian+statically+linked+root+shell
 
 So it has been brought up before, over 2 years ago, and it's still
 wrong? 

The point was that the answer to your question (Is this the first...)
is readily available from the usual place.  Your assignment is to read
the earlier posts and either:

  - Formulate a previously unaddressed reason root should have a
statically linked shell, rather than pollute the list with largely
irrelevent dialog.

  - Understand why the current alternative(s) are sufficient.

  - Summarize findings to list and quietly exit the topic.

Peace.

-- 
Karsten M. Self kmself@ix.netcom.comhttp://kmself.home.netcom.com/
 What Part of Gestalt don't you understand?
   Moderator, Free Software Law Discussion mailing list:
 http://lists.alt.org/mailman/listinfo/fsl-discuss/


pgpMgZZCjmb1h.pgp
Description: PGP signature


Re: Serious Bug in most major Linux distros.

2002-05-25 Thread Colin Watson
On Sat, May 25, 2002 at 12:32:02AM -0700, Karsten M. Self wrote:
 on Wed, May 22, 2002, Petro ([EMAIL PROTECTED]) wrote:
  So it has been brought up before, over 2 years ago, and it's still
  wrong? 
 
 The point was that the answer to your question (Is this the first...)
 is readily available from the usual place.  Your assignment is to read
 the earlier posts and either:
 
   - Formulate a previously unaddressed reason root should have a
 statically linked shell, rather than pollute the list with largely
 irrelevent dialog.
 
   - Understand why the current alternative(s) are sufficient.
 
   - Summarize findings to list and quietly exit the topic.

  - If you find something that should be done, file a bug report or talk
to a more appropriate mailing list.

-- 
Colin Watson  [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Serious Bug in most major Linux distros.

2002-05-24 Thread Petro
On Thu, May 23, 2002 at 04:32:39PM -0700, Karl E. Jorgensen wrote:
 On Thu, May 23, 2002 at 02:38:15PM -0700, Petro wrote:
major snipage
  Yes. Or just figuring out if there is even a wreck, how it
 happened
  etc. 
   with the intent of restoring the wreckage rather than scrapping
 it.
   Reread the quoted text from Karl.
  I know what he is saying, and he's right in a limited way. If your
  entire ability to administer a system envolves unpacking .debs and
  answering the configure questions they ask, a static shell is
  pointless. 
  I'm not in that position. 
 
 I have to disagree with your implication (entire ability).  I
 suspect that you have some high levels of frustration showing through
 here.

Yes, there is some level of frustration. 

 My previous post was assuming:
 a)  you have hosed some essential library - ld-linux, libc, whatever. 
 b)  you want to repair it (later on it transpired that you were happy
 just
 to rescue the data before scrapping the lot, which will mean a
 different approach).
 
 With that in mind, you may well want to re-extract the damaged file(s)
 out of a .deb  (e.g. one you have conveniently left floating around in
 /var/cache/apt/archives).

If one has a small set of utilities that do not depend on external
libraries, a SA with a bit of creative thinking and nimble fingers
can accomplish a lot. 

The others (those without creative thinking and nimble fingers) are
screwed blue anyway. 

The desire is for a small set of standard tools statically compiled
so *IF NOTHING ELSE* I can determine just how badly a system is
horked. There are about 37.38 billion ways a system can wind up in
an unstable or stochastic state, from mv * .. in /lib (I a much more
complex and lengthy equivelent of that in a shell script on a OS X
box 2 weeks ago) to memory or filehandle exhaustion, to a corrupt
file etc. 

Some of these *do* require a reinstall. Some of these just require a
reboot. Others require different handling. 

In an installation with more than 1 computer, and the right tools
statically linked, most would not require the ability to extract
.debs, but if all that requires is ar and gzip, then that's not too
much to ask. 

I'm starting a list of tools that should be available in a static
format. I don't know what I'm going to so about it yet, but I have
discovered a wierdness in bash debian source package. 

There is a define in debian/rules in that package that is: 
# build a statically linked bash?
with_static = yes


However, the default rules file doesn't use it anywhere, and
adding:
ifeq ($(with_static),yes)
 conf_args += --enable-static-link
endif

to what appears to be the appropriate section gives this diff:
115,117c115,117
 LIBS = $(BUILTINS_LIB) $(LIBRARIES) 
 LDFLAGS =  -static $(STATIC_LD) $(LOCAL_LDFLAGS) $(PROFILE_FLAGS) $(CFLAGS)
 STATIC_LD = -static
---
 LIBS = $(BUILTINS_LIB) $(LIBRARIES) -ldl 
 LDFLAGS =  $(STATIC_LD) $(LOCAL_LDFLAGS) $(PROFILE_FLAGS)
 $(CFLAGS)
 STATIC_LD = 

Which, oddly enough doesn't seem to build a static bash executable. 

Hmmm...


-- 
My last cigarette was roughly 32 days, 14 hours, 7 minutes ago.
YHBW


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Serious Bug in most major Linux distros.

2002-05-23 Thread Rob Ransbottom
On Wed, 22 May 2002, Petro wrote:

  on Tue, May 21, 2002, Petro ([EMAIL PROTECTED]) wrote:
   All I'm asking for at this point is something that the rest of the
   Unix World has done forever, a statically linked /sbin/sh for
  roots
   use. 
 
 So it has been brought up before, over 2 years ago, and it's still
 wrong? 

It is not wrong, it just yields little protection.  Just from the disk
getting corrupted under an in core shell.  This will only be of benefit
if you need to keep your machine up about .9 of the time.
Even then I ask:  You _want_ to keep your users going when your shared
libs are flakey???

Shared libs could implement a load_all_required_functions routine.
This would let a program getuid and act like it had static libs.

I just keep a rescue partition loaded with debian-base.  This
has lots of benefits.  And having your normal root environment is 
nice in stressful situations.


rob Live the dream.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Serious Bug in most major Linux distros.

2002-05-23 Thread Petro
On Thu, May 23, 2002 at 01:04:17PM -0400, Rob Ransbottom wrote:
 On Wed, 22 May 2002, Petro wrote:
  So it has been brought up before, over 2 years ago, and it's still
  wrong? 
 
 It is not wrong, it just yields little protection.  Just from the disk
 getting corrupted under an in core shell.  This will only be of benefit
 if you need to keep your machine up about .9 of the time.
 Even then I ask:  You _want_ to keep your users going when your shared
 libs are flakey???

I don't have users in the normal sense. I run clusters of web and
database servers, things that are hard to keep backed up 100%. 

I do have a few users, but they are mostly developers, and on their
staging and dev boxes it might be necessary at some point to get in
and recovery certain bits. 

But it's not just about *me*, I can, because of the resources I have
available to me in a medium sized installation (currently around 100
servers) take a box down and replace it with another one until I
have time to get down the colo and do things some other way. 

Not everyone has this luxury. 

 Shared libs could implement a load_all_required_functions routine.
 This would let a program getuid and act like it had static libs.

This sounds more complex, and unnecessary complexity is not a good
thing. 

 I just keep a rescue partition loaded with debian-base.  This
 has lots of benefits.  And having your normal root environment is 
 nice in stressful situations.

That isn't a bad idea. 

-- 
My last cigarette was roughly 31 days, 9 hours, 3 minutes ago.
YHBW


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Serious Bug in most major Linux distros.

2002-05-23 Thread dman
On Wed, May 22, 2002 at 05:28:13PM -0700, Petro wrote:
| On Tue, May 21, 2002 at 10:15:45PM -0700, dman wrote:
|  On Tue, May 21, 2002 at 07:08:48PM -0700, Petro wrote:
|  | On Tue, May 21, 2002 at 05:57:16PM -0700, Karl E. Jorgensen wrote:
|  |  On Tue, May 21, 2002 at 05:04:59PM -0700, Petro wrote:
|  |   Mostly just some basic copy tools. 
|  |  If you need to pick things out of .debs, then you'll need a working
|  |  dpkg. Or ar + tar (  gzip if memory serves).
|  | Actually, just tar and cp. 
|  A deb is an ar archive that contains two gzipped tarballs.  Thus you
|  first need ar to extract the tarballs, then gunzip to decompress them,
|  and then finally tar and cp to do the rest.
| 
| Yes, and with cp and tar I can either get a file from somewhere
| else, or copy some files to a location where they will survive a
| reinstall. 

Oh, you're looking to salvage something from the wreckage before
scrapping it.  The comment above was about pulling files out of a .deb
with the intent of restoring the wreckage rather than scrapping it.
Reread the quoted text from Karl.

|  |  Correction: Relatively easy, and a relatively large amount of
|  work...
|  | Doesn't sound like it. 
|  Building tweaked binary packages from the source package is really
|  easy, as long as your tweaks are major rewrites of the app or
|  something.
| 
| No, I meant it doesn't sound like a lot of work. 

I didn't get that the first time.

-D

-- 

One OS to rule them all, one OS to find them,
One OS to bring them all and in the darkness bind them,
In the Land of Redmond, where the Shadows lie.
 
GnuPG key : http://dman.ddts.net/~dman/public_key.gpg



pgpky1EA9f24J.pgp
Description: PGP signature


Re: Serious Bug in most major Linux distros.

2002-05-23 Thread Petro
On Thu, May 23, 2002 at 01:26:16PM -0700, dman wrote:
 On Wed, May 22, 2002 at 05:28:13PM -0700, Petro wrote:
 | On Tue, May 21, 2002 at 10:15:45PM -0700, dman wrote:
 |  On Tue, May 21, 2002 at 07:08:48PM -0700, Petro wrote:
 |  | On Tue, May 21, 2002 at 05:57:16PM -0700, Karl E. Jorgensen wrote:
 |  |  On Tue, May 21, 2002 at 05:04:59PM -0700, Petro wrote:
 |  |   Mostly just some basic copy tools. 
 |  |  If you need to pick things out of .debs, then you'll need a
 working
 |  |  dpkg. Or ar + tar (  gzip if memory serves).
 |  | Actually, just tar and cp. 
 |  A deb is an ar archive that contains two gzipped tarballs.  Thus you
 |  first need ar to extract the tarballs, then gunzip to decompress
 them,
 |  and then finally tar and cp to do the rest.
 | 
 | Yes, and with cp and tar I can either get a file from somewhere
 | else, or copy some files to a location where they will survive a
 | reinstall. 
 Oh, you're looking to salvage something from the wreckage before
 scrapping it.  The comment above was about pulling files out of a .deb

Yes. Or just figuring out if there is even a wreck, how it happened
etc. 

 with the intent of restoring the wreckage rather than scrapping it.
 Reread the quoted text from Karl.

I know what he is saying, and he's right in a limited way. If your
entire ability to administer a system envolves unpacking .debs and
answering the configure questions they ask, a static shell is
pointless. 

I'm not in that position. 

 |  |  Correction: Relatively easy, and a relatively large amount of
 |  work...
 |  | Doesn't sound like it. 
 |  Building tweaked binary packages from the source package is really
 |  easy, as long as your tweaks are major rewrites of the app or
 |  something.
 | No, I meant it doesn't sound like a lot of work. 
 I didn't get that the first time.

Yeah, sometimes I'm a little too terse. Less isn't always more. 

-- 
My last cigarette was roughly 31 days, 12 hours, 8 minutes ago.
YHBW


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Serious Bug in most major Linux distros.

2002-05-23 Thread Karl E. Jorgensen
On Thu, May 23, 2002 at 02:38:15PM -0700, Petro wrote:
 On Thu, May 23, 2002 at 01:26:16PM -0700, dman wrote:
  On Wed, May 22, 2002 at 05:28:13PM -0700, Petro wrote:
  | On Tue, May 21, 2002 at 10:15:45PM -0700, dman wrote:
  |  On Tue, May 21, 2002 at 07:08:48PM -0700, Petro wrote:
  |  | On Tue, May 21, 2002 at 05:57:16PM -0700, Karl E. Jorgensen wrote:
  |  |  On Tue, May 21, 2002 at 05:04:59PM -0700, Petro wrote:
  |  |   Mostly just some basic copy tools. 
  |  |  If you need to pick things out of .debs, then you'll need a
  working
  |  |  dpkg. Or ar + tar (  gzip if memory serves).
  |  | Actually, just tar and cp. 
  |  A deb is an ar archive that contains two gzipped tarballs.  Thus you
  |  first need ar to extract the tarballs, then gunzip to decompress
  them,
  |  and then finally tar and cp to do the rest.
  | 
  | Yes, and with cp and tar I can either get a file from somewhere
  | else, or copy some files to a location where they will survive a
  | reinstall. 
  Oh, you're looking to salvage something from the wreckage before
  scrapping it.  The comment above was about pulling files out of a .deb
 
 Yes. Or just figuring out if there is even a wreck, how it happened
 etc. 
 
  with the intent of restoring the wreckage rather than scrapping it.
  Reread the quoted text from Karl.
 
 I know what he is saying, and he's right in a limited way. If your
 entire ability to administer a system envolves unpacking .debs and
 answering the configure questions they ask, a static shell is
 pointless. 
 
 I'm not in that position. 

I have to disagree with your implication (entire ability).  I
suspect that you have some high levels of frustration showing through
here.

My previous post was assuming:
a)  you have hosed some essential library - ld-linux, libc, whatever. 
b)  you want to repair it (later on it transpired that you were happy just
to rescue the data before scrapping the lot, which will mean a
different approach).

With that in mind, you may well want to re-extract the damaged file(s)
out of a .deb  (e.g. one you have conveniently left floating around in
/var/cache/apt/archives).

-- 
Karl E. Jørgensen
[EMAIL PROTECTED]
www.karl.jorgensen.com
I'm currently out trying to find myself. If I should get back before I
return, please keep me here.


pgphlqb5DZ5U2.pgp
Description: PGP signature


Re: Serious Bug in most major Linux distros.

2002-05-22 Thread dman
On Tue, May 21, 2002 at 07:08:48PM -0700, Petro wrote:
| On Tue, May 21, 2002 at 05:57:16PM -0700, Karl E. Jorgensen wrote:
|  On Tue, May 21, 2002 at 05:04:59PM -0700, Petro wrote:
| 
|   Mostly just some basic copy tools. 
|  If you need to pick things out of .debs, then you'll need a working
|  dpkg. Or ar + tar (  gzip if memory serves).
| 
| Actually, just tar and cp. 

A deb is an ar archive that contains two gzipped tarballs.  Thus you
first need ar to extract the tarballs, then gunzip to decompress them,
and then finally tar and cp to do the rest.

|  Correction: Relatively easy, and a relatively large amount of work...
| 
| Doesn't sound like it. 

Building tweaked binary packages from the source package is really
easy, as long as your tweaks are major rewrites of the app or
something.

-D

-- 

He who walks with the wise grows wise,
but a companion of fools suffers harm.
Proverbs 13:20
 
GnuPG key : http://dman.ddts.net/~dman/public_key.gpg



pgpE0SWXRsVRM.pgp
Description: PGP signature


Re: Serious Bug in most major Linux distros.

2002-05-22 Thread Karsten M. Self
on Tue, May 21, 2002, Petro ([EMAIL PROTECTED]) wrote:

 All I'm asking for at this point is something that the rest of the
 Unix World has done forever, a statically linked /sbin/sh for roots
 use. 
 
 Is this the first time someone has brought this up? 

Puhleaze:

http://www.google.com/search?q=debian+statically+linked+root+shell

-- 
Karsten M. Self kmself@ix.netcom.comhttp://kmself.home.netcom.com/
 What Part of Gestalt don't you understand?
Microsoft offers them the one thing most business people will pay
any price for - the ability to say we had no choice - everyone's
doing it that way.
 -- Andrew Grygus  http://www.aaxnet.com/


pgp2DU3hTwzQB.pgp
Description: PGP signature


Re: Serious Bug in most major Linux distros.

2002-05-22 Thread Colin Watson
On Wed, May 22, 2002 at 03:16:57AM -0700, Karsten M. Self wrote:
 on Tue, May 21, 2002, Petro ([EMAIL PROTECTED]) wrote:
  All I'm asking for at this point is something that the rest of the
  Unix World has done forever, a statically linked /sbin/sh for roots
  use. 
  
  Is this the first time someone has brought this up? 
 
 Puhleaze:
 
 http://www.google.com/search?q=debian+statically+linked+root+shell

One thing that comes to mind quite quickly is that statically linked
binaries are a major maintenance overhead. Every time a bug is fixed in
one of the libraries you use, you have to recompile the binary and
reupload, which is a particular pain when trying to freeze the base
system.

As a case in point, I had to do a non-maintainer upload of sash a couple
of months ago because it statically links against zlib and so needed to
be manually rebuilt to acquire the zlib security fix.

-- 
Colin Watson  [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Serious Bug in most major Linux distros.

2002-05-22 Thread Petro
On Tue, May 21, 2002 at 10:15:45PM -0700, dman wrote:
 On Tue, May 21, 2002 at 07:08:48PM -0700, Petro wrote:
 | On Tue, May 21, 2002 at 05:57:16PM -0700, Karl E. Jorgensen wrote:
 |  On Tue, May 21, 2002 at 05:04:59PM -0700, Petro wrote:
 |   Mostly just some basic copy tools. 
 |  If you need to pick things out of .debs, then you'll need a working
 |  dpkg. Or ar + tar (  gzip if memory serves).
 | Actually, just tar and cp. 
 A deb is an ar archive that contains two gzipped tarballs.  Thus you
 first need ar to extract the tarballs, then gunzip to decompress them,
 and then finally tar and cp to do the rest.

Yes, and with cp and tar I can either get a file from somewhere
else, or copy some files to a location where they will survive a
reinstall. 


 |  Correction: Relatively easy, and a relatively large amount of
 work...
 | Doesn't sound like it. 
 Building tweaked binary packages from the source package is really
 easy, as long as your tweaks are major rewrites of the app or
 something.

No, I meant it doesn't sound like a lot of work. 


-- 
My last cigarette was roughly 30 days, 13 hours, 56 minutes ago.
YHBW


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Serious Bug in most major Linux distros.

2002-05-22 Thread Petro
On Wed, May 22, 2002 at 03:16:57AM -0700, Karsten M. Self wrote:
 on Tue, May 21, 2002, Petro ([EMAIL PROTECTED]) wrote:
  All I'm asking for at this point is something that the rest of the
  Unix World has done forever, a statically linked /sbin/sh for
 roots
  use. 
  
  Is this the first time someone has brought this up? 
 Puhleaze:

There's a bunch of people here acting like they've never heard of
the idea, and the only somewhat reasonable excuse I've heard for not
doing it is It's a lot of work, which lead me to believe it hadn't
been discussed here. 

 http://www.google.com/search?q=debian+statically+linked+root+shell

So it has been brought up before, over 2 years ago, and it's still
wrong? 


-- 
My last cigarette was roughly 30 days, 15 hours, 21 minutes ago.
YHBW


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Serious Bug in most major Linux distros.

2002-05-21 Thread Sean 'Shaleh' Perry
 
 Why the sam hell is there not, by default, no questions asked, it's
 installed because it's *right*, a statically linked /sbin/sh as
 roots default shell? 
 

because the days of static bins are long passed.  if *you* want this, Debian
makes it even easier.  apt-get install sash.  not only is is statically linked
it also includes enough stuff to help you save a system.

Debian is very strongly against making any decision for you we do not have to
make.  And almost all of our decisions can be overruled.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Serious Bug in most major Linux distros.

2002-05-21 Thread Richard Cobbe
Lo, on Tuesday, May 21, Sean 'Shaleh' Perry did write:

Where's the attribution?  Who was the OP?

  Why the sam hell is there not, by default, no questions asked, it's
  installed because it's *right*, a statically linked /sbin/sh as
  roots default shell? 

 because the days of static bins are long passed.  

In most cases, yes.  However, the OP has a point.  Consider:

[vimes:~]$ ldd /bin/bash
libncurses.so.5 = /lib/libncurses.so.5 (0x40016000)
libdl.so.2 = /lib/libdl.so.2 (0x40055000)
libc.so.6 = /lib/libc.so.6 (0x40059000)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000)

On my potato box, /lib/libc.so.6 is a symlink to libc-2.1.3.so.  If I've
fscked up that symlink, bash won't load.  Certain binaries, particularly
/bin/sh and /bin/ln, need to be statically linked to allow root to
recover from problems like this.  If you don't want to statically link
/bin/ln, then make sure that /sbin/ldconfig is statically linked.

(On my system, at least, ldconfig is statically linked.  Still doesn't
help much if I can't get to it because my shell won't load.)

 if *you* want this, Debian makes it even easier.  apt-get install
 sash.  not only is is statically linked it also includes enough stuff
 to help you save a system.
 
 Debian is very strongly against making any decision for you we do not
 have to make.  And almost all of our decisions can be overruled.

True, but I really can't see any harm in making root's shell a
statically-linked binary, myself.  After all, how many root shells do
you expect to have running at one time?

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Serious Bug in most major Linux distros.

2002-05-21 Thread Noah Meyerhans
On Tue, May 21, 2002 at 01:32:48PM -0700, Sean 'Shaleh' Perry wrote:
 Debian is very strongly against making any decision for you we do not have to
 make.  And almost all of our decisions can be overruled.

But we make the decision to include a dynamically linked shell as root's
login shell, which goes against years of accumulated wisdom in the Unix
world.

We try to avoid making decisions on behalf of our user, but shouldn't
the decisions that we *do* make be the right ones?  This isn't simply a
matter of opinion.  There is a very valid technical reason that root's
shell should be statically linked.  Why don't we ship with that
configuration by default?

noah

-- 
 ___
| Web: http://web.morgul.net/~frodo/
| PGP Public Key: http://web.morgul.net/~frodo/mail.html 


pgpa43EwMFGfX.pgp
Description: PGP signature


Re: Serious Bug in most major Linux distros.

2002-05-21 Thread Ron Johnson
On Tue, 2002-05-21 at 17:02, Noah Meyerhans wrote:
 On Tue, May 21, 2002 at 01:32:48PM -0700, Sean 'Shaleh' Perry wrote:
  Debian is very strongly against making any decision for you we do not have 
  to
  make.  And almost all of our decisions can be overruled.
 
 But we make the decision to include a dynamically linked shell as root's
 login shell, which goes against years of accumulated wisdom in the Unix
 world.
 
 We try to avoid making decisions on behalf of our user, but shouldn't
 the decisions that we *do* make be the right ones?  This isn't simply a
 matter of opinion.  There is a very valid technical reason that root's
 shell should be statically linked.  Why don't we ship with that
 configuration by default?

After reading this thread, I decided to install sash.  Interestingly,
the default installation doesn't overwrite root's default shell, but
creates a _new_ root account, and even clones the password from
/etc/shadow.
  root:x:0:0:root:/root:/bin/bash
  sashroot:x:0:0:root:/root:/bin/sash
 
-- 
+-+
| Ron Johnson, Jr.Home: [EMAIL PROTECTED] |
| Jefferson, LA  USA  http://ronandheather.dhs.org:81 |
| |
| I have created a government of whirled peas...|
|   Maharishi Mahesh Yogi, 12-May-2002,   |
!   CNN, Larry King Live  |
+-+


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Serious Bug in most major Linux distros.

2002-05-21 Thread Vincent Lefevre
On Tue, May 21, 2002 at 17:18:08 -0500, Ron Johnson wrote:
 After reading this thread, I decided to install sash.

I did that too. Is there a reason why it isn't installed by default?

-- 
Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Serious Bug in most major Linux distros.

2002-05-21 Thread Peter Corlett
Vincent Lefevre  [EMAIL PROTECTED] wrote:
 On Tue, May 21, 2002 at 17:18:08 -0500, Ron Johnson wrote:
 After reading this thread, I decided to install sash.
 I did that too. Is there a reason why it isn't installed by default?

It seems that the only merit sash has is that it is statically linked. I
find it to be a horrible shell otherwise, and I'd rather not have that as
the default root shell on my boxes.

I'm not sure you gain much by being able to log in if libc is shafted since
it's pretty much reinstall time by then anyway...


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Serious Bug in most major Linux distros.

2002-05-21 Thread Karl E. Jorgensen
On Tue, May 21, 2002 at 12:58:48PM -0700, Petro wrote:
 
 This is something that has been bothering me for a while now. 
 
 See, you guys who put these distributions together are pretty
 bright. It takes a lot of work, and I see a lot of the discussions
 that go in to figuring out all the nit-picky little details that
 give polish to a distribution. 
 
 However, one thing is driving me absolutely Bug F*** crazy. 
 
 I use, or have used several versions of RedHat and SuSe, and now I'm
 on my second version of Debian. 
 
 Why the sam hell is there not, by default, no questions asked, it's
 installed because it's *right*, a statically linked /sbin/sh as
 roots default shell? 

You do have a valid point, but a statically linked root shell will not
always work. At least you shouldn't rely on it being sufficient...

If you were to nuke /lib/ld-linux.so* (or other essential libraries),
then chances are that you won't be able to log in anyway:

$ ldd /sbin/getty
libc.so.6 = /lib/libc.so.6 (0x4001d000)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000)

[OK. I admit that if you can find an already-running getty, this may be
a moot point]

$ ldd /bin/login
libcrypt.so.1 = /lib/libcrypt.so.1 (0x4001d000)
libpam.so.0 = /lib/libpam.so.0 (0x4004a000)
libpam_misc.so.0 = /lib/libpam_misc.so.0 (0x40053000)
libdl.so.2 = /lib/libdl.so.2 (0x40056000)
libc.so.6 = /lib/libc.so.6 (0x40059000)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000)

Besides, even /sbin/init is dynamically linked, so a severly damaged
system won't be able to boot...

So, to follow your line of thought (i think), then at least getty 
login need to be statically linked too. And init if you plan on
rebooting using only the existing (hypothetically damaged) root fs. And
you need to prepare by having root's login shell be statically linked.

To repair such a system you may need other tools, e.g. dpkg, ar, apt-get
(which for the purposes of this, are rather inconveniently located in
/usr), mount, tar and gzip. All of which (i believe) are dynamically
linked.

As others have suggested, sash will help here - assuming that you can
log in...

Another solution could be to boot your kernel with init=/bin/sash. And
make sure that this boots with the root fs in read-write mode; as the
mount command is dynamically linked...

At least you should always be able to boot from the install floppies,
and mount/fsck your root filesystem from there. If not, then it's time
for you to create new boot floppies. The standard ones may not have a
suitable kernel if you have some esoteric hardware...

HTH
-- 
Karl E. Jørgensen
[EMAIL PROTECTED]
www.karl.jorgensen.com
 Today's fortune:
Torque is cheap.


pgpJUEfpmkyfM.pgp
Description: PGP signature


Re: Serious Bug in most major Linux distros.

2002-05-21 Thread Tom Cook
On  0, Richard Cobbe [EMAIL PROTECTED] wrote:
  Debian is very strongly against making any decision for you we do not
  have to make.  And almost all of our decisions can be overruled.
 
 True, but I really can't see any harm in making root's shell a
 statically-linked binary, myself.  After all, how many root shells do
 you expect to have running at one time?

One for every cron or at job... at least.

Tom
-- 
Tom Cook
Information Technology Services, The University of Adelaide

Beware of computer programmers that carry screwdrivers.
- Leonard Brandwein

Get my GPG public key: 
https://pinky.its.adelaide.edu.au/~tkcook/tom.cook-at-adelaide.edu.au


pgphhZDKuBDse.pgp
Description: PGP signature


Re: Serious Bug in most major Linux distros.

2002-05-21 Thread Noah Meyerhans
On Tue, May 21, 2002 at 10:42:53PM +, Peter Corlett wrote:
 It seems that the only merit sash has is that it is statically linked. I
 find it to be a horrible shell otherwise, and I'd rather not have that as
 the default root shell on my boxes.
 
 I'm not sure you gain much by being able to log in if libc is shafted since
 it's pretty much reinstall time by then anyway...

Not a bit.  I have recovered systems that had libc blown away.  I've
recovered systems that had all of /usr blown away...

sash is handy because not only is it statically linked, but it has many
common utilities *built in*, so if you blow away libc, not only do you
still have a shell, but you still have the tools that you're likely to
need to recover it.

Having a shell that is uncomfortable as root's shell is not
necessarily a bad thing, either.  You really shouldn't be spending too
much time as root, and, the way I see it, if you're spending enough time
there that you need tab completion and other advanced shell features,
you're probably doing too much as root.  Besides, you can always exec
bash if you really need it.

noah

-- 
 ___
| Web: http://web.morgul.net/~frodo/
| PGP Public Key: http://web.morgul.net/~frodo/mail.html 


pgp5XFMVs3hAO.pgp
Description: PGP signature


Re: Serious Bug in most major Linux distros.

2002-05-21 Thread Petro
On Tue, May 21, 2002 at 01:32:48PM -0700, Sean 'Shaleh' Perry wrote:
  
  Why the sam hell is there not, by default, no questions asked, it's
  installed because it's *right*, a statically linked /sbin/sh as
  roots default shell? 
  
 
 because the days of static bins are long passed.  

For most things, I'd agree. For certain critical binaries, that is
pure unadalterated hubris. 

The was to hose a system are manifold, as are the paths to recovery
of that system, and to not do the simplest thing--like providing a
sane and statically linked /sbin/sh for root is silly. 

 if *you* want this, Debian
 makes it even easier.  apt-get install sash.  not only is is statically linked
 it also includes enough stuff to help you save a system.

I want it the *default*. It will be in the next interation of my
production installation. 

 Debian is very strongly against making any decision for you we do not have to
 make.  And almost all of our decisions can be overruled.

You make *lots* of decisions for the end user. Most of them are
*very* sane. 

This one is not. 


-- 
My last cigarette was roughly 29 days, 14 hours, 21 minutes ago.
YHBW


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Serious Bug in most major Linux distros.

2002-05-21 Thread Petro
On Tue, May 21, 2002 at 01:32:48PM -0700, Sean 'Shaleh' Perry wrote:
  Why the sam hell is there not, by default, no questions asked, it's
  installed because it's *right*, a statically linked /sbin/sh as
  roots default shell? 
 because the days of static bins are long passed.  if *you* want this, Debian
 makes it even easier.  apt-get install sash.  not only is is statically linked
 it also includes enough stuff to help you save a system.
 Debian is very strongly against making any decision for you we do not have to
 make.  And almost all of our decisions can be overruled.

Also, CCing somebody who has not been so rude as to say CC me
please I don't read the list isn't necessary. 

-- 
My last cigarette was roughly 29 days, 14 hours, 27 minutes ago.
YHBW


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Serious Bug in most major Linux distros.

2002-05-21 Thread Petro
On Tue, May 21, 2002 at 10:42:53PM +, Peter Corlett wrote:
 Vincent Lefevre  [EMAIL PROTECTED] wrote:
  On Tue, May 21, 2002 at 17:18:08 -0500, Ron Johnson wrote:
  After reading this thread, I decided to install sash.
  I did that too. Is there a reason why it isn't installed by default?
 
 It seems that the only merit sash has is that it is statically linked. I
 find it to be a horrible shell otherwise, and I'd rather not have that as
 the default root shell on my boxes.

If the system is working fine, then you just type bash (or tcsh, if
you're twisted that way) and go on about your business.

 I'm not sure you gain much by being able to log in if libc is shafted since
 it's pretty much reinstall time by then anyway...

That depends a lot on how it's shafted. 

As well, there could be a few things to do before a reinstall that
make it a lot less painful. 

-- 
My last cigarette was roughly 29 days, 14 hours, 28 minutes ago.
YHBW


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Serious Bug in most major Linux distros.

2002-05-21 Thread Petro
On Tue, May 21, 2002 at 03:46:47PM -0700, Karl E. Jorgensen wrote:
 On Tue, May 21, 2002 at 12:58:48PM -0700, Petro wrote:
  This is something that has been bothering me for a while now. 
  See, you guys who put these distributions together are pretty
  bright. It takes a lot of work, and I see a lot of the discussions
  that go in to figuring out all the nit-picky little details that
  give polish to a distribution. 
  However, one thing is driving me absolutely Bug F*** crazy. 
  I use, or have used several versions of RedHat and SuSe, and now I'm
  on my second version of Debian. 
  Why the sam hell is there not, by default, no questions asked, it's
  installed because it's *right*, a statically linked /sbin/sh as
  roots default shell? 
 You do have a valid point, but a statically linked root shell will not
 always work. At least you shouldn't rely on it being sufficient...

You don't rely on your airbag (no, not your local politician, the
one in your car) being sufficent, nor your seat belt (or if you ride
a motorcycle, your Helmet etc.), however you want them there when
you need them, right? 

 If you were to nuke /lib/ld-linux.so* (or other essential libraries),
 then chances are that you won't be able to log in anyway:
 $ ldd /sbin/getty
   libc.so.6 = /lib/libc.so.6 (0x4001d000)
   /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000)
 [OK. I admit that if you can find an already-running getty, this may be
 a moot point]
 $ ldd /bin/login
   libcrypt.so.1 = /lib/libcrypt.so.1 (0x4001d000)
   libpam.so.0 = /lib/libpam.so.0 (0x4004a000)
   libpam_misc.so.0 = /lib/libpam_misc.so.0 (0x40053000)
   libdl.so.2 = /lib/libdl.so.2 (0x40056000)
   libc.so.6 = /lib/libc.so.6 (0x40059000)
   /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000)
 Besides, even /sbin/init is dynamically linked, so a severly damaged
 system won't be able to boot...

I'm not so much worried about rebooting, as trying to diagnois and
scavange an already running system. 

 So, to follow your line of thought (i think), then at least getty 
 login need to be statically linked too. And init if you plan on
 rebooting using only the existing (hypothetically damaged) root fs. And
 you need to prepare by having root's login shell be statically linked.

Yeah, it might be a good idea to build static versions of those as
well. 

 To repair such a system you may need other tools, e.g. dpkg, ar, apt-get
 (which for the purposes of this, are rather inconveniently located in
 /usr), mount, tar and gzip. All of which (i believe) are dynamically
 linked.

Mostly just some basic copy tools. 

Looks like I'm going to have to learn how to make custom debs. 

 As others have suggested, sash will help here - assuming that you can
 log in...
 Another solution could be to boot your kernel with init=/bin/sash. And
 make sure that this boots with the root fs in read-write mode; as the
 mount command is dynamically linked...
 
 At least you should always be able to boot from the install floppies,
 and mount/fsck your root filesystem from there. If not, then it's time
 for you to create new boot floppies. The standard ones may not have a
 suitable kernel if you have some esoteric hardware...

You say that like I can wander over and stick a floppy in.

The vast majority of my machines, and the ones I worry about are 50
miles from here. 




-- 
My last cigarette was roughly 29 days, 14 hours, 30 minutes ago.
YHBW


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Serious Bug in most major Linux distros.

2002-05-21 Thread Petro
On Tue, May 21, 2002 at 04:51:08PM -0700, Tom Cook wrote:
 On  0, Richard Cobbe [EMAIL PROTECTED] wrote:
   Debian is very strongly against making any decision for you we do not
   have to make.  And almost all of our decisions can be overruled.
  True, but I really can't see any harm in making root's shell a
  statically-linked binary, myself.  After all, how many root shells do
  you expect to have running at one time?
 One for every cron or at job... at least.

/sbin/sh and /bin/sh do not have to be the same binary. 

-- 
My last cigarette was roughly 29 days, 14 hours, 38 minutes ago.
YHBW


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Serious Bug in most major Linux distros.

2002-05-21 Thread Karl E. Jorgensen
On Tue, May 21, 2002 at 05:04:59PM -0700, Petro wrote:
 On Tue, May 21, 2002 at 03:46:47PM -0700, Karl E. Jorgensen wrote:

  You do have a valid point, but a statically linked root shell will not
  always work. At least you shouldn't rely on it being sufficient...
 
 You don't rely on your airbag (no, not your local politician, the
 one in your car) being sufficent, nor your seat belt (or if you ride
 a motorcycle, your Helmet etc.), however you want them there when
 you need them, right? 

Yep. As long as it is practical. It depends on how far you think is
practical.  (I wouldn't rely on my politician either). At some point,
the extra effort simply isn't worth it. You seem to want to go further;
that's OK. As long as I'm not forced to.

[ snip, snip, snip ]

  To repair such a system you may need other tools, e.g. dpkg, ar, apt-get
  (which for the purposes of this, are rather inconveniently located in
  /usr), mount, tar and gzip. All of which (i believe) are dynamically
  linked.
 
 Mostly just some basic copy tools. 

If you need to pick things out of .debs, then you'll need a working
dpkg. Or ar + tar (  gzip if memory serves).

 Looks like I'm going to have to learn how to make custom debs. 

If you really must, then it should be relatively easy to apt-get
source, apply a patch, fakeroot debian/rules binary. In fact, you
should end up with a quite small patch (depending on the package in
question); enough to at least semi-automate the process for future
versions. And you probably need your own (small-ish) debian mirror.

Correction: Relatively easy, and a relatively large amount of work...

[ snip, snip, snip ]

  At least you should always be able to boot from the install floppies,
  and mount/fsck your root filesystem from there. If not, then it's time
  for you to create new boot floppies. The standard ones may not have a
  suitable kernel if you have some esoteric hardware...
 
 You say that like I can wander over and stick a floppy in.
 
 The vast majority of my machines, and the ones I worry about are 50
 miles from here. 

Point taken. But for some types of failures, you'll *have* to get out of
the chair anyway :-)

-- 
Karl E. Jørgensen
[EMAIL PROTECTED]
www.karl.jorgensen.com
I'm currently out trying to find myself. If I should get back before I
return, please keep me here.


pgpygqfflaTsg.pgp
Description: PGP signature


Re: Serious Bug in most major Linux distros.

2002-05-21 Thread Paul 'Baloo' Johnson
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 21 May 2002, Peter Corlett wrote:

 It seems that the only merit sash has is that it is statically linked. I
 find it to be a horrible shell otherwise, and I'd rather not have that as
 the default root shell on my boxes.

So if you can't use the machine any other way, pass init=/bin/sash (or
whatever it's location is) to the kernel on boot...

- -- 
Baloo


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE86uomNtWkM9Ny9xURApSLAJ4yqst5rgcGVVn3CsAHTv5C5XvRSQCdEl9Y
l6sjq9AT98kQJcgGb9oGIHw=
=trgw
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Serious Bug in most major Linux distros.

2002-05-21 Thread Petro
On Tue, May 21, 2002 at 05:57:16PM -0700, Karl E. Jorgensen wrote:
 On Tue, May 21, 2002 at 05:04:59PM -0700, Petro wrote:
  On Tue, May 21, 2002 at 03:46:47PM -0700, Karl E. Jorgensen wrote:
   You do have a valid point, but a statically linked root shell will
 not
   always work. At least you shouldn't rely on it being sufficient...
  You don't rely on your airbag (no, not your local politician, the
  one in your car) being sufficent, nor your seat belt (or if you
 ride
  a motorcycle, your Helmet etc.), however you want them there when
  you need them, right? 
 Yep. As long as it is practical. It depends on how far you think is
 practical.  (I wouldn't rely on my politician either). At some point,
 the extra effort simply isn't worth it. You seem to want to go further;
 that's OK. As long as I'm not forced to.

All I'm asking for at this point is something that the rest of the
Unix World has done forever, a statically linked /sbin/sh for roots
use. 

Is this the first time someone has brought this up? 

  Mostly just some basic copy tools. 
 If you need to pick things out of .debs, then you'll need a working
 dpkg. Or ar + tar (  gzip if memory serves).

Actually, just tar and cp. 

  Looks like I'm going to have to learn how to make custom debs. 
 If you really must, then it should be relatively easy to apt-get
 source, apply a patch, fakeroot debian/rules binary. In fact, you
 should end up with a quite small patch (depending on the package in
 question); enough to at least semi-automate the process for future
 versions. And you probably need your own (small-ish) debian mirror.
 
  Heck, I've already got three, or 6 if you consider non-US to be a
  seperate mirror. 

 Correction: Relatively easy, and a relatively large amount of work...

Doesn't sound like it. 

 [ snip, snip, snip ]
   suitable kernel if you have some esoteric hardware...
  You say that like I can wander over and stick a floppy in.
  The vast majority of my machines, and the ones I worry about are 50
  miles from here. 
 Point taken. But for some types of failures, you'll *have* to get out of
 the chair anyway :-)

Not the way I'm planning it. 

At this point in time I can reinstall any of my Debian and almost
all of my Redhat boxes (with one exception) from either here (work)
or home. I have roughly 5% spares (meaning that with the exception
of some specialized hardware) I an lose and regenerate 5% of my
servers w/out cutting in to my capacity. I've also got about 30%
spare capacity in most of my clusters, so I can lose a box or three
out of most clusters and not miss them even during peak loads. 

The thing is, I want to be able to get in to certain boxes and get
the (money) logs off before I nuke them. 

However, that is *my* specific case. 

As I iterated earlier, and am re-iterating now, there are a
multitude of reasons for a small set of statically linked programs
on a network connected machine. Root's shell is definately one of
those. 

-- 
My last cigarette was roughly 29 days, 16 hours, 34 minutes ago.
YHBW


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]