TUHS

tuhs@tuhs.org

2 participants
6532 discussions

Re: [TUHS] was turmoil, moving to rm -rf /

by John Floren

On 2017-04-27, Ron Natalie <ron(a)ronnatalie.com> wrote: > This is a multipart message in MIME format. > > ------=_NextPart_000_0154_01D2BF90.27157840 > Content-Type: text/plain; > charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > Exec 8 (the Univac Operating Systm) used to make you type the word = >=E2=80=9CCATASTROPHIC=E2=80=9D to proceed past a certain point in = > reiniting the system. > > > ------=_NextPart_000_0154_01D2BF90.27157840 > Content-Type: text/html; > charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > ><html xmlns:v=3D"urn:schemas-microsoft-com:vml" = > xmlns:o=3D"urn:schemas-microsoft-com:office:office" = > xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = > xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta = > http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"><meta = > name=3DGenerator content=3D"Microsoft Word 14 (filtered = > medium)"><style></style></head><body lang=3DEN-US link=3Dblue = > vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span = > style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497= > D'>Exec 8 (the Univac Operating Systm) used to make you type the word = >=E2=80=9CCATASTROPHIC=E2=80=9D to proceed past a certain point in = > reiniting the system.</span><span = > style=3D'font-size:9.0pt;font-family:"Helvetica","sans-serif"'><o:p></o:p= >></span></p></div></body></html> > ------=_NextPart_000_0154_01D2BF90.27157840-- > Ron, can you and others who are posting via email please take care to send text-only emails? It's utterly unreadable to anyone using a newsreader or plain old 'mail'. http://i.imgur.com/EJS5Okd.png sorry for going off-topic... john

8 years, 2 months

Re: [TUHS] There is turmoil in Linux-land - When did rm first avoid going upwards?

by jnc＠mercury.lcs.mit.edu

> From: Josh Good > Would the command "cd /tmp ; rm -rf .*" be able to kill a V6 ... system? Looking at the vanilla 'rm' source for V6, it cannot/does not delete directories; one has to use the special 'rmdir' command for that. But, somewhat to my surprise, it does support both the '-r' and '-f' flags, which I thought were later. (Although not as 'stacked' flags, so you'd have to say 'rm -r -f'.) So, assuming one did that, _and_ (important caveat!) _performed that command as root_, it probably would empty out the entire directory tree. (I checked, and "cd /tmp ; echo .*" evaluates to ". .." on V6. Noel

8 years, 2 months

directories going away.

by Ron Natalie

The JHU version of the V6 kernel and the mount program were modified (or should I say buggered) so that unprivileged users could mount user packs. There were certain restrictions added as well: no setuid on mounted volumes etc. The problem came up that people would mount them using relative paths and the mtab wouldn't really show who was using the disk as a result. I suggested we just further bugger it by making the program chdir to '/dev' first. That way you wouldn't have to put /dev/ on the drive device and you'd have to give an absolute path for the mount point (or at least one relative to /dev). I pointed out to my coworker that there was nothing in /dev/ to mount on. He started trying it. Well the kernel issued errors for trying to use a special file as a mount point. He then tried "." Due to a combination of bugs that worked! The only problem, is how do you unmount it? The /dev nodes had been replaced by the root of directory of my user pack. Oh well, go halt and reboot. There were supposed to be protections against this. Mind you I did not have root access at this point (just a lowly student operator), so we decided to see where else we could mount. Sure enough cd /etc/ and mount on "." there. We made up our own password file. It had one account with uid 0 and the name "Game Player" in the gcos field. About this one of the system managers calls and tells us to halt the machine as it'd had been hacked. I told him we were responsible and we'd undo what we did. I think by this time Mike Muuss came out and gave me the "mount" source and told me to fix it.

8 years, 2 months

Re: [TUHS] 8th Edition Research Unix on SIMH

by norman＠oclsc.org

Tim Newsham: I'm not sure what fd 3 is intended to be, but its the telnet socket in p9p. ==== By the 10/e days, file descriptor 3 was /dev/tty. There was no more magic driver for /dev/tty; the special file still existed, but it was a link to /dev/fd/3. Similarly /dev/stdin stdout stderr were links to /dev/fd/0 1 2. (I mean real links, not mere symbolic ones.) I have a vague recollection that early on /dev/tty was fd/127 instead, but that changed somewhere in the middle 8/e era. None of which says what Plan 9 did with that file descriptor, though I suppose it could possibly have copied the /dev/tty use. And none of that excuses the hard-coded magic number file descriptor, but hackers will be hackers. Norman Wilson Toronto ON

8 years, 2 months

8th Edition Research Unix on SIMH

by David du Colombier

Here are my notes to run 8th Edition Research Unix on SIMH. http://9legacy.org/9legacy/doc/simh/v8 These notes are quite raw and unpolished, but should be sufficient to get Unix running on SIMH. Fell free to use, improve and share. -- David du Colombier

8 years, 2 months

Re: [TUHS] was turmoil, moving to rm -rf /

by David

Many years ago I was at Burroughs and they wanted to do Unix (4.1c) on a new machine. Fine. We all started on the project porting from a Vax. So far so good. Then a new PM came in and said that intel was the future and we needed to use their machines for the host of the port. And an intel rep brought in their little x86 box running some version of Unix (Xenix?, I didn’t go anywhere near the thing). My boss, who was running the Unix port project did the following: Every Friday evening he would log into the intel box as root and run “/bin/rm -rf /“ from the console. Then turn off the console and walk away. Monday morning found the box dead and the intel rep would be called to come and ‘fix’ his box. This went on for about 4 weeks, and finally my boss asked the intel rep what was wrong with his machine. The rep replied that this was ‘normal’ for the hardware/software and we would just have to “get used to it”. The PM removed the intel box a couple of days later. David > On Apr 25, 2017, at 7:19 AM, tuhs-request(a)minnie.tuhs.org wrote: > > From: Larry McVoy <lm(a)mcvoy.com> > To: Clem Cole <clemc(a)ccc.com> > Cc: Larry McVoy <lm(a)mcvoy.com>, TUHS main list <tuhs(a)minnie.tuhs.org> > Subject: Re: [TUHS] was turmoil, moving to rm -rf / > Message-ID: <20170425140853.GD24499(a)mcvoy.com> > Content-Type: text/plain; charset=us-ascii > > Whoever was the genuis that put mknod in /etc has my gratitude. > We had other working Masscomp boxen but after I screwed up that > badly nobody would let me near them until I fixed mine :) > > And you have to share who it was, I admitted I did it, I think > it's just a thing many people do..... Once :)

8 years, 2 months

Apple Darwin 0.1 and 0.3 sort of running on x86!

by Jason Stevens

I don't know if this is of any interest to anyone here, but 1999 is 18 years ago, so maybe it counts as old? Over on nextcomputers.org various users had found a backup of next68k.org which included a wget of the old source http://nextftp.onionmixer.net/next.68k.org/otto/html/pub/Darwin/PublicSource /Darwin/index.html So I found a copy of Rhapsody DR-2, the last binary version of this Mach 2.5+4.4BSD and after a day got a kernel to build. Another day and I had it interfacing to the driverkit to load drivers. After a post on reddit someone gave me a link to some kdx p2p network, where they had a Darwin 0.3 toast image. using what I learned with Darwin 0.1 I got the 0.3 to build as well. I uploaded a bunch of stuff here: https://sourceforge.net/projects/aapl-darwin/ although it seems to not let me upload the toast images themselves. I did slam together a minimal Darwin 0.3 qemu image that can sort-of boot to single user mode. It's not even slightly useful, but it does show that it works. https://sourceforge.net/projects/aapl-darwin/files/qemu-images/Darwin03_qemu 090_24_4_2017.7z/download

8 years, 2 months

Re: [TUHS] There is turmoil in Linux-land - When did rm first avoid going upwards?

by jnc＠mercury.lcs.mit.edu

> From: Kurt H Maier > /etc/glob, which appears to report no-match if the first character is . So I couldn't be bothered to work out how 'glob' worked exactly, so I just did an experiment: I created a hacked version of 'rm' that had the directory handling call to glob call 'echo' instead of 'rm'; it also printed 'tried' instead of the actual unlink call, and printed 'cd' when it changed directories. I then set up two subsidiary directors, foo and .bar, with one containing '.foo0 foo1' and the other '.bar0 bar1'. Saying 'xrm -r -f .*' produced this: cd: . -r -f foo xrm xrm.c cd: .. -r -f foo xrm xrm.c cd: .bar -r -f bar1 (This system has /tmp on a mounted file system, which is why the 'cd ..' was a NOP. And a very good thing, too; at one point the phone rang, and it distracted me, and I automatically typed 'rm', not 'xrm'... see below for what happened. No biggie, there were only my test files there. The output lines are "-r -f foo xrm xrm.c" because that's what 'glob' passed to 'echo'.) Saying 'xrm -r -f *' produced this: cd: foo -r -f foo1 xrm: tried xrm.c: tried So apparently 'glob', when presented with '*' , ignores entries starting with '.', but '.*' does not. When I stupidly typed 'rm -r -f .*', it did more or les what I originally thought it would: deleted all the files in all the directories (but only on the /tmp device, because .. linked to the itself in /tmp, so it didn't escape from that volume); leaving all the directories, but empty, except for the files .foo0 and .bar0. So files and inferior directories with names starting with '.' would have escaped, but nothing else. Noel

8 years, 2 months

Re: [TUHS] There is turmoil in Linux-land - When did rm first avoid going upwards?

by jnc＠mercury.lcs.mit.edu

> From: "Ron Natalie" > Actually, it's the shell that calls glob. Yes, in the initial expansion of the command line, but V6 'rm' also uses 'glob' internally; if the '-r' flag is given, and the current name in the command argument list is a directory, viz.: if ((buf->mode & 060000) == 040000) { if (rflg) { ... execl("/etc/glob", "glob", "rm", "-r", fflg? "-f": "*", fflg? "*": p, 0); printf("%s: no glob\n", arg); exit(); } (where 'p' is 0 - no idea why the writer didn't just say '"*": 0, 0'). So "rm -f foo*", where the current directory contains file 'foo0 foo1 foo2' and directoty 'foobar', and directory 'foobar' contains 'bar0 bar1 bar2', the first instance of 'glob' (run by the shell) expands the 'foo0 foo1 foo2 foobar' and the second instance (run by 'rm') expands the 'bar0 bar1 bar2'. > Glob then invokes the command (in this case rm). I don't totally grok 'glob', but it is prepared to exec() either the command name, /bin/{command} or /usr/bin/{command}; but if that file is not executable it tries feeding it to the shell, on the assumption it must be a shell command list: execv(file, arg); if (errno==ENOEXEC) { arg[0] = file; *--arg = "/bin/sh"; execv(*arg, arg); } I guess (too lazy to look) that the execv() must return a different error number if the file doesn't exist at all, so it only tries the shell if the file existed, but wasn't executable. Noel

8 years, 2 months

Runaway rm -r

by Ron Natalie

There was an incident at Pixar that a runaway rm ate most of the Toy Story 2 movie. The only thing that saved them was an employee had their own copy on a machine at home. We never lost the whole disk through one of these, but we did have a guy wipe out /etc/passwd one day. Our password fields had an rfc-822ish user name in the gcos field, so it looked something like: ron::51:50:Ronald Natalie <ron>:/sys1/ron: Well, one of our users decided to grep for a user (alas while root) with the command grep <howard> /etc/passwd

8 years, 2 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS