mike@x.co.uk (Mike Moore) (10/04/90)
Here's one (do NOT actually do this, it appears to be lethal):
mv /bin/sh /bin/sh.bin
create a shell script called /bin/sh with the following
if [ $USER = "root" ]
then
/bin/sh.bin
else
/bin/rsh
fi
log out and log back in (assuming that your passwd file has you set to
use /bin/sh
you can't (can't exec a shell of course).
now assume that *everyone* is set to use /bin/sh (including root), how
do you get out of this without rebuilding the operating system? I don't
think there actually is one..... but....
--
---
Mike Moore
mike@x.co.uk or mike@ixi-limited.co.uk
Usual and obvious disclaimers... etcbrnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/05/90)
In article <Oct90.150551.3649@x.co.uk> mike@x.co.uk (Mike Moore) writes: > Here's one (do NOT actually do this, it appears to be lethal): [ move /bin/sh, then you *don't* get it on reboot, so you're stuck ] Wow. I have an even better solution along the same lines: Remove all your files. Yep, that does it. Even better: Bomb your computer center. Or just kill yourself. Some reboot procedures let you sneak data in to init, and some inits have options to use csh or other programs on reboot. ---Dan
ewsres15@pc.usl.edu (Vignes Gerard M) (10/05/90)
In article <Oct90.150551.3649@x.co.uk> mike@x.co.uk (Mike Moore) writes: >Here's one (do NOT actually do this, it appears to be lethal): >now assume that *everyone* is set to use /bin/sh (including root), how >do you get out of this without rebuilding the operating system? I don't >think there actually is one..... but.... I once loaded an operating system and foolishly set the default shell to KSH before bothering to load the KSH binary. Even more foolishly, I then logged out, and was greeted by a cannot execute type message when I tried to log back in. I gave up after about an hour and reloaded the system. Thinking back, I had the networking software going and probably could have FTP'd the KSH binary (or a new copy of /etc/passwd) over as root. I'm not certain if this would have worked, but I know that it was a real PITA to reload the system, and I felt pretty silly about it afterwards.
datri@convex.com (Anthony A. Datri) (10/06/90)
>>now assume that *everyone* is set to use /bin/sh (including root), how That would be pretty silly, now wouldn't it? >>do you get out of this without rebuilding the operating system? I don't >>think there actually is one..... but.... Boot the miniroot and do a restore. --
lcuff@spectrum.CMC.COM (Leonard Cuff) (10/06/90)
In article <Oct90.150551.3649@x.co.uk> mike@x.co.uk (Mike Moore) writes: >Here's one (do NOT actually do this, it appears to be lethal): >now assume that *everyone* is set to use /bin/sh (including root), how >do you get out of this without rebuilding the operating system? I don't >think there actually is one..... but.... Some versions of UNIX are distributed on floppies and the boot floppy can be used to mount the hard disk (after stopping the installation process early on). The password file could then be edited, or whatever other hacks come to mind. I have recovered System V/386 systems from AT&T, 386 systems from Interactive (ISC) and ancient Callan systems (SVR2) using this technique. It tends to be ugly, because you have to know the device name(s) of your partitions and you must use full paths that have this ugly prefix, and an editor like vi doesn't typically work 'cos it can't find its termcap or terminfo files, but one can muddle along with sed. This technique is helpful in a variety of scenarios, most of them involving badly munched hard disks: bad boot block on the hard disk, bad fsck, bad passwd file, you get the idea..... Lots of fun. :-) -- Leonard Cuff if ( my_words == Rockwells_words ) lcuff@cmc.com hell_freezes_over = now; "I feel like a fugitive from th' law of averages" - Bill Mauldin
hahn@nas.nasa.gov (Jonathan Hahn) (10/06/90)
In article <Oct90.150551.3649@x.co.uk> mike@x.co.uk (Mike Moore) writes: >Here's one (do NOT actually do this, it appears to be lethal): > > mv /bin/sh /bin/sh.bin > >create a shell script called /bin/sh with the following If your sys admin is on top of things, s/he would simply boot off an alternate root pack (prepared ahead of time, obviously), then mount and repair the primary root fs. The crisis would be no more traumatic than an ordinary reboot. If you're not so lucky, there are still alternatives. If you're on SYSV, I believe there is (at least there used to be) a suite of stand-alone utilities which could be used to repair the damage. On bsd, you could build and boot a mini-root in your your swap partition and mount & fix the primary root fs, but it would be a pain. >-- >--- >Mike Moore >mike@x.co.uk or mike@ixi-limited.co.uk -jonathan hahn -- hahn@gigantor.nas.nasa.gov wk: (415) 604-4360 ..!ames!amelia!hahn hm: (408) 736-7014
wchuang@athena.mit.edu (Mithrandir) (10/06/90)
In article <Oct90.150551.3649@x.co.uk> mike@x.co.uk (Mike Moore) writes: >Here's one (do NOT actually do this, it appears to be lethal): > > mv /bin/sh /bin/sh.bin > >create a shell script called /bin/sh with the following > >if [ $USER = "root" ] > then > /bin/sh.bin > else > /bin/rsh >fi > >log out and log back in (assuming that your passwd file has you set to >use /bin/sh > >you can't (can't exec a shell of course). > >now assume that *everyone* is set to use /bin/sh (including root), how >do you get out of this without rebuilding the operating system? I don't >think there actually is one..... but.... > >Mike Moore >mike@x.co.uk or mike@ixi-limited.co.uk >Usual and obvious disclaimers... etc Reboot the workstation, enter single-user mode and move /bin/sh.bin back to /bin/sh. -- ---------------------------------------------William Chuang MIT '91 ARPA: wchuang@athena.mit.edu BITNET: wchuang%athena.mit.edu@MITVMA.BITNET UUCP: ...!mit-eddie!athena.mit.edu!wchuang
wchuang@athena.mit.edu (Mithrandir) (10/06/90)
In article <Oct90.150551.3649@x.co.uk> mike@x.co.uk (Mike Moore) writes: >Here's one (do NOT actually do this, it appears to be lethal): > > mv /bin/sh /bin/sh.bin > >create a shell script called /bin/sh with the following > >if [ $USER = "root" ] > then > /bin/sh.bin > else > /bin/rsh >fi > >log out and log back in (assuming that your passwd file has you set to >use /bin/sh > >you can't (can't exec a shell of course). > >now assume that *everyone* is set to use /bin/sh (including root), how >do you get out of this without rebuilding the operating system? I don't >think there actually is one..... but.... > >Mike Moore >mike@x.co.uk or mike@ixi-limited.co.uk >Usual and obvious disclaimers... etc On a single-machine, you could reboot the workstation, bring it up in single-user mode, and move /bin/sh.bin back to /bin/sh. ---------------------------------------------William Chuang MIT '91 ARPA: wchuang@athena.mit.edu BITNET: wchuang%athena.mit.edu@MITVMA.BITNET UUCP: ...!mit-eddie!athena.mit.edu!wchuang -- ---------------------------------------------William Chuang MIT '91 ARPA: wchuang@athena.mit.edu BITNET: wchuang%athena.mit.edu@MITVMA.BITNET UUCP: ...!mit-eddie!athena.mit.edu!wchuang
tif@doorstop.austin.ibm.com (Paul Chamberlain) (10/08/90)
In article <1990Oct6.042126.24228@athena.mit.edu> wchuang@athena.mit.edu (Mithrandir) writes: >In article <Oct90.150551.3649@x.co.uk> mike@x.co.uk (Mike Moore) writes: >> mv /bin/sh /bin/sh.bin >On a single-machine, you could reboot the workstation, bring it up in >single-user mode, and move /bin/sh.bin back to /bin/sh. What command interpreter do you expect to use in single-user mode? Every machine I've used (Near-Unices), uses /bin/sh. Paul Chamberlain | I do NOT represent IBM. tif@doorstop, sc30661 at ausvm6 512/838-7008 | ...!cs.utexas.edu!ibmaus!auschs!doorstop.austin.ibm.com!tif
jbayer@ispi.COM (Jonathan Bayer) (10/09/90)
wchuang@athena.mit.edu (Mithrandir) writes: >Reboot the workstation, enter single-user mode and move /bin/sh.bin back >to /bin/sh. Won't work, because single-user mode also uses /bin/sh. JB -- Jonathan Bayer Intelligent Software Products, Inc. (201) 245-5922 500 Oakwood Ave. jbayer@ispi.COM Roselle Park, NJ 07204
dave@viper.Lynx.MN.Org (David Messer) (10/11/90)
In article <Oct90.150551.3649@x.co.uk> mike@x.co.uk (Mike Moore) writes: > > [Description of replacing /bin/sh with a script deleted] > >you can't [login] (can't exec a shell of course). > >now assume that *everyone* is set to use /bin/sh (including root), how >do you get out of this without rebuilding the operating system? I think the only way out of this is to reboot from your distribution media (floppies or whatever) and mv the executable sh back to /bin/sh. You shouldn't have to rebuild the operating system though. -- Spelling is for computers. | David Messer dave@Lynx.MN.Org -or- | Lynx Data Systems ...!bungia!viper!dave
jms@tardis.Tymnet.COM (Joe Smith) (10/20/90)
In article <1990Oct6.042126.24228@athena.mit.edu> wchuang@athena.mit.edu (Mithrandir) writes: >>mv /bin/sh /bin/sh.in # now you're stuck >On a single-machine, you could reboot the workstation, bring it up in >single-user mode, and move /bin/sh.bin back to /bin/sh. You can only do that on a system where the single-user shell is something other than /bin/sh. One such example is SunOS 4.0 and later. When a Sun system comes up single-user, the kernel starts up /sbin/init which invokes /sbin/sh. (/usr/bin/sh is not used since /usr is often NFS mounted.) -- Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com or jms@gemini.tymnet.com BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-C41 | BIX: smithjoe | 12 PDP-10s still running! "POPJ P," San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga 3000 speaks for me."