Re: Serious Bug in most major Linux distros.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
-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.
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]