TUHS

tuhs@tuhs.org

49 participants
6506 discussions

by Steve Simon

hi the other early vm system not mentioned yet is the one Charles Forsyth wrote at the university of york for sunos. i never used it as i was learning v7 on an interdata 30 miles away at the time but i read his excellent paper on it. -Steve

5 years, 8 months

Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]

by Rudi Blom

Whenever I hear UNIX, networking and streams I have to think about this scheme. Still using this, even on HP-UX 11.31 on Itanium rx-servers Cheers, uncle rubl

5 years, 8 months

Re: [TUHS] Running v10

by Norman Wilson

Check out "Setting Up a Research UNIX System" by Norman Wilson. troff sources are in v10. ==== But that assumes you're being given a root image to copy to the disk initially, no? We never made a general-purpose distribution tape; we just made one-off snapshots when someone wanted a copy of the system in the 10/e era. Is there a binary root image in Warren's archive? I forget. Norman Wilson Toronto ON (where the weather feels like NJ these days, dammit)

5 years, 8 months

ARS Technica on UNIX @ 50

by Clem Cole

https://arstechnica.com/gadgets/2019/08/unix-at-50-it-starts-with-a-mainfra…

5 years, 8 months

systime

by Steve Simon

wow, systime. i went for a student placement there but didnt get it - i guess my long hair (then) didn't fit as the interview seemed good. i had a mate who was working late on the day the combined uk police and CIA (it was said) arrived to shut them down, and tell them they ARE being taken over by CDC. the crime was selling systime re-badged vaxes to the ussr at the height of the cold war. seem odd now that they thought they could get away with it. exciting times. -Steve

5 years, 8 months

Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]

by Doug McIlroy

> Doug McIlroy <doug(a)cs.dartmouth.edu> wrote: > >> >>> How long was research running on a PDP-11 and when did they move to a VAX? >> >> London and Reiser had ported Unix to the VAX, replete with virtual memory, in 1978. By the time v7 was released (1979), Vaxen had become the workhorse machines in Research. >> >> Doug > > So, what's the story on why the London/Reiser port didn't get adapted > back by Research, and they ended up starting from 4.1 BSD? > > Thanks, > > Arnold Sorry, what I said about London/Reiser is true, but not the whole story. L/R didn't have demand paging; BSD did. Doug

5 years, 8 months

Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]

by Doug McIlroy

> How long was research running on a PDP-11 and when did they move to a VAX? London and Reiser had ported Unix to the VAX, replete with virtual memory, in 1978. By the time v7 was released (1979), Vaxen had become the workhorse machines in Research. Doug

5 years, 8 months

Lions Commentary on Unix

by Clem Cole

Gentlefolk, Does anyone have an original copy of the Lions text. All I have is the new printed version and my nth generation photocopy from 1975. There is another 50th event occurring a few weeks that would love to be able to borrow a copy for an artifact display. Reply to me off-list if you can help. Clem

5 years, 9 months

DEC's MIPS product (was If not Linux, then what?)

by Paul Winalski

On 8/28/19, Clem Cole <clemc(a)ccc.com> wrote: > > So, I think the MIPS product was a holding pattern while DEC got it's > strategy together. Alpha would really show up until later (I would leave > LCC and go to DEC to be apart if that). Also note Alpha was brought > up/debugged on Ultrix and of course, Prism sort of had Ultrix on it. But > I think using the MIPS chip keep them in the game, when Vax was dying and > RISC was the word on the street. I was in DEC's compiler development team at the time, working on the new GEM common back end, and this matches my recollection. The original plan was for GEM to be the successor to the VAX Code Generator (VCG, the common back end used by DEC's PL/I, Ada, C/C++ and a few other compilers on VAX/VMS) and its first target was the VMS personality module Prism's OS, Mica. Prism was close to delivering silicon when it was cancelled in favor of Alpha. DEC's MIPS-based products were done as a stopgap until Alpha was ready. The GEM group implemented a MIPS code generator. I don't recall whether we actually shipped any GEM-based products on the MIPS/Ultrix platform. GEM focused on Alpha (on VMS, Unix, and Windows host and target platforms) shortly thereafter. -Paul W.

5 years, 9 months

dmr streams & networking [was: Re: If not Linux, then what?]

by Paul Ruizendaal

> I find it hard to believe what you remember Dennis saying. The point of > dmr's streams was to support networking research in the lab and avoid the > myriad bugs of the mpx interface by stepping around them completely. > > Perhaps it's out of context. > > -rob > I could be wrong but that's my memory. What he told me was streams was > for line disciplines for tty drivers. That's what I know but you were > there, I was not. I'm pretty confused because what Dennis said to me > was that he did not think streams would work for networking, he thought > they made sense for a stream but not for a networking connection because > that had multiple connections coming up through a stream. There is some contemporary material that gives a bit of context. The quotes are a bit contradictory and perhaps reflect evolving views. [1] The original dmr paper (1984) on streams (http://cm.bell-labs.co/who/dmr/st.html) seems to support the no networking view, focussing on terminal handling in its discussion. Also, near the end it says: "Streams are linear connections; by themselves, they support no notion of multiplexing, fan-in or fan-out. [...] It seems likely that a general multiplexing mechanism could help in both cases, but again, I do not yet know how to design it.” This seems to exclude usage for networking, which is typically multiplexed. [2] However, now that the V8 sources are available it is clear that the streams mechanism was used (by dmr?) to implement TCP/IP networking. He explains how that tallies with the above quote on multiplexing in a 1985 usenet post: https://groups.google.com/forum/#!topicsearchin/net.unix-wizards/subject$3A… The config files in the surviving TUHS V8 source tree actually match with the setup that dmr described in the penultimate paragraph. If the post by dmr does not immediately appear, click on the 8-10-85 post by 'd...(a)dutoit.xn--uucp-y96a to make it fold out. For ease of reference, I’m including the message text below. <quote> Steven J. Langdon claimed that without multiplexing one couldn't do a proper kernel-resident version of TCP/IP in the V8 stream context. Here's how it's done. It is still true in our system that stream multiplexing does not occur, in the sense that every stream connection has (from the point of view of the formal data structures) exactly two ends, one at a user process, and the other at a device or another process. However, this has, in practice, not turned out to be a problem. Say you have a hardware device that hands you packets with a channel (or socket) number buried inside in some complicated format. The general scheme to handle the situation uses both a line discipline (stream filter module) and associated code that, to the system, looks like a stream device driver with several minor devices; these have entries in /dev. A watchdog process opens the underlying real device, and pushes the stream module. Arriving packets from the real device are passed to this module, where they are analyzed, and then given to the appropriate associated pseudo-device. Likewise, messages written on the pseudo-device are shunted over to the line discipline, where they are encoded appropriately and sent to the real device. This is where the multiplexing-demultiplexing occurs; formally, it is outside of the stream structure, because the data-passing doesn't follow the forward and backward links of the stream modules. However, the interfaces of the combined larger module obey stream rules. For example, IP works this way: The IP line discipline looks at the type field of data arriving from the device, and determines whether the packet is TCP or UDP or ARP or whatever, and shunts it off to the stream associated with /dev/ip6 or /dev/ip17 or whatever the numbers are. TCP, of course, is multiplexed as well. So there is a TCP line discipline, and a bunch of TCP devices; a watchdog process opens /dev/ip6, and pushes the TCP line discipline; then the TCP packets it gets are parcelled out to the appropriate /dev/tcpXX device. Each TCP device looks like the end of a stream, and may, of course, have other modules (e.g. tty processor) inserted in this stream. UDP sits on top of IP in the same way. This example is complicated, because (TCP,UDP)/IP is. However, it works well. In particular, the underlying real device can be either an ethernet or our own Datakit network; the software doesn't care. For example, from my machine, I can type "rlogin purdy" and connect to a Sequent machine running 4.2; the TCP connection goes over Datakit to machine "research" where it is gatewayed to a local ethernet that purdy is connected to. A further generalization (that we haven't made) is in principle easy: there can be protocol suites other than IP on an Ethernet cable. So there could be another layer to separate IP from XNS from Chaosnet, etc. Dennis Ritchie </quote> Maybe the subtle notion expressed as "formally, it is outside of the stream structure, because the data-passing doesn't follow the forward and backward links of the stream modules. However, the interfaces of the combined larger module obey stream rules” explains how dmr could talk about streams as being just suitable for line disciplines without meaning to say that they did not have good use in networking. Paul

5 years, 9 months

/dev/null

by Norman Wilson

John Steinhart: Just curious - am doing a cross-country road trip with my kid and saw a Wisconsin dev null license plate. Didn't get a look at the driver. ===== It's in ken/mem.c in Fourth Edition, dmr/mem.c in Fifth and Sixth. Norman (no sheds) Wilson Toronto ON

5 years, 9 months

/dev/null

by Jon Steinhart

Just curious - am doing a cross-country road trip with my kid and saw a Wisconsin dev null license plate. Didn't get a look at the driver. Does it belong to anyone on this list? Jon

5 years, 9 months

Shell builtin exec

by Adam Thornton

This is probably the place to ask: I understand why the shell builtin "exec" is the same as the syscall exec() in the sense of "replace this process with that one." But why is it also the way to redirect filehandles in the current shell? (That is, why isn't the redirection named something else?) Adam

5 years, 9 months

Re: [TUHS] Video of PDP-7 with Graphics-2?

by Warren Toomey

On Fri, Aug 02, 2019 at 06:49:19PM -0400, Jim Carpenter wrote: > On 8/2/19 4:14 PM, Warren Toomey wrote: > > Hi all, I'm chasing the Youtube video of the PDP-7 at Bell Labs where > > people are using it to draw circuit schematics. > > A Bell Labs video? The only Bell Labs video I remember seeing that had > someone doing circuit schematics had it being done on a PDP-5. The -7 was > shown later doing music stuff. (That's the -7 that I thought maybe Unix > started life on.) Thanks Jim, Is it this one? https://www.youtube.com/watch?v=iwVu2BWLZqA They mention a Graphics-1 device, so maybe I'm getting this confused with the PDP-7 and the Graphics-2. Cheers, Warren

5 years, 9 months

Re: [TUHS] Set-uid shell scripts

by Norman Wilson

Oops. Didn't think it through: the problem is argv[1], passed as the name of the script being executed, not argv[0]. Disregard my previous execl(...). A related problem is the inherent race condition: If you do ln -s /bin/setuidscript . ./setuidscript ./setuidscript is opened twice: once when the kernel reads it and finds #! as magic number and execs the interpreter, a second time when the interpreter opens ./setuidscript. If you meanwhile run something that swoops in in the background and replaces ./setuidscript with malicious instructions for the interpreter, you win. I remember managing to do this myself at one point in the latter part of the 1980s. That was when I fell out of love with setuid interpreter scripts. It looks like we didn't disable the danger in the Research kernel, though. I don't remember why not. Norman Wilson Toronto ON

5 years, 9 months

Re: [TUHS] Additional groups and additional directory permissions

by Kirk McKusick

> Date: Fri, 2 Aug 2019 09:28:18 -0400 > From: Clem Cole <clemc(a)ccc.com> > To: Aharon Robbins <arnold(a)skeeve.com>, Doug McIlroy <doug(a)cs.dartmouth.edu> > Cc: The Eunuchs Hysterical Society <tuhs(a)tuhs.org> > Subject: Re: [TUHS] Additional groups and additional directory permissions > > The best I can tell/remember is that groups went through 4 phases: > 1.) No groups (earliest UNIX) [ I personally never used this except in the > V0 retrocomputing] > 2.) First group implementation (Thompson) [My first UNIX introduction was > with this implementation] > 3.) PWB 1.0 (Mashey version) [then saw this post PWB] > 4.) BSD 4.2 (wnj version) [and lived this transistion] > > Each was a little different in semantics. > > As Doug mentioned, many sites (like Research) really did not need much and > groups were really not used that widely. Thompson added something like > the Project number of TOPS and some earlier systems. Truth is, it did not > help much IMO. It was useful for grouping things like the binaries and > keeping some more privileged programs from having to be setuid root. > > Mashey added features in PWB, primarily because of the RJE/Front end to the > Mainframes and the need to have better protections/collections of certain > items. But they still were much more like the DEC PPN, were you were > running as a single group (i.e. the tuple UID/GID). This lasted a pretty > long time, as it worked reasonably well for larger academic systems, where > you had a user and were assigned a group, say for a course or class, you > might be talking. If you looked at big 4.1 BSN Vaxen like at Purdue/Penn > State, *etc.*, that how they were admin'd. But as Doug said, if you were > still a small site, the use of groups was still pretty shallow. > > But, as part of the CSRG support for DARPA, there was a push from the > community to have a list of groups that a user could be a part and you > carried that list around in a more general manner. The big sites, in > particular, were pushing for this because they were using groups as a major > feature. wnj implemented same and it would go out widely in 4.2, although > >>by memory<< that was in 4.1B or 4.1C first. It's possible Robert Elz > may have brought that to Bill with his quota changes, but frankly I've > forgotten. There was a lot of work being done to the FS at that point, > much less Kirk's rewrite. > > But as UNIX went back to workstations, the need for a more general group > system dropped away until the advent widely used distributed file systems > like CMU's AFS and Sun's NFS. Then the concept of a user being in more > than one group became much more de rigeur even on a small machine. > > Clem Late to answer... As far as I remember, Clem's description is correct. The filesystem itself stores only one owner and one group ID. When checking access to the file, the file owner is checked to see if the user ID matches. If so, then the owner permissions are applied. If not then the group array associated with the user is used to decide if the group of the file matches one of the groups of which the user is a member and if so the group permissions apply. Otherwise the other permissions are used. In BSD, the group assigned to the file is assigned from the group of the directory in which it is created. The setgid flag can be set only if that group is a member of the user's group array. The user can only change the group ID to one that appears in their group array. Until multiple group sets were added to System V, the group of the file was taken from the gid assigned to the user at login. Kirk McKusick

5 years, 9 months

Pre-init initialization

by Grant Taylor

Do, or did, anything other than Linux use a concept of an initramfs / initrd to create a pre-(main)-init initialization environment to prepare the system to execute the (main)-init process? -- Grant. . . . unix || die

5 years, 9 months

MERT aka UNIX/RT

by Warner Losh

Greetings, I was wondering if there were any early versions of MERT available? Reading different sources, it appears that MERT was a real time kernel that used EMT traps to implement unix system calls (from around V4 or V5 given the timelines) on top of a real time executive (though some sources seem to imply it was a derivative of V4, most disagree). I see this in our archives https://wiki.tuhs.org/doku.php?id=misc:snippets:mert1 which is quite handy for discover its (and other early) unix lineages for a talk I'm doing in about a month. Now that we have sources, I go back and double check the recollections of things like this to see if version numbers were right, etc. But I can't do that with MERT at all. I can find the Bell Systems Technical Journal for Unix that has a brief article on it, but no sources to double check. So I thought I'd ask here if we have any MERT artifacts I can look at that have escaped my casual browsing of the archive. So far I've just found an email from Kevin Bowling on the topic from last month with no replies. And a similar thread from 2002, plus pleading from time to time (I can't tell if Warren or Noel wants it more :). I guess the same could be said for CB-UNIX and UNIX/TS, though I see a USDL/CB_Unix directory in the archive I could look at :). Warner

5 years, 9 months

Re: [TUHS] Set-uid shell scripts

by Dave Horsfall

On Tue, 6 Aug 2019, Lyndon Nerenberg wrote: >> Just to extend this thread a bit more, when did the set[ug]id bit start >> getting turned off if the file was overwritten? > > I'm pretty sure that's been the case since the dawn of time. Hmmm... I have this vague memory of V5 (which I only used for a couple of months before we got V6) not clearing that bit, but after all these years my memory is starting to fail me :-( > It was certainly the case in every System V (release 0 and beyond) I > worked with, along with many BSDs derivatives (SunOS 3+, Ultrix, etc). > (And Xenix, which had it's own insanity that I now think selinux is > trying to inflict on me.) I've always thought that Xenix was insane to start with... Then again, my first experience with it was on a 286... Now, when porting Unify, should I use large memory model here or small memory model? Crazy. > This has been documented in chown(2) for as long as I can remember, so > that's a good place to start if you want to dig back through the various > source trees. I don't have access to the sources right now, but I'll take your word for it; it was just a passing thought. -- Dave

5 years, 9 months

Running Research Unix v3 on simh

by Benito Buchheim

Hello everyone, My name is Benito Buchheim and I am a computer science student at Hasso-Plattner-Institute in Germany. During our Operating Systems Course we came across The Unix Heritage Society, more specifically Research Unix Version 3, and took a look into the source code of this version. The idea arose to try to get this running somehow as a sort of voluntary task. So I started digging my way through the available material and quickly found the "modified_nsys" version by Warren Toomey, which conveniently contained a very detailed readme file on how to compile and run this version on a Unix v5 emulator. Thus, I started cloning the simh Github Repository and built the pdp11 emulator. After downloading the v5root disk image and figuring out how to use simh to run it, I had a working Unix v5, but struggled a bit to copy more than one file onto it using the emulated devices. In the end, I used a very Hacky way and wrote a short python script which just runs the emulator and "copy pastes" the folder structure into the image. I now thought to be ready to start working my way through Toomey's readme. Unfortunately already the first command failed quite miserably. I changed my working directory and ran the first shell script to compile the kernel, but cc spat out loads of error messages which are not very detailed. As this is a very early version of c code I am kinda stuck at this point and running a bit out of ideas on what may have gone wrong. As there is this mailing list we thought to have a chat with the experts. Maybe there is somebody who could help or give a hint on how to get this running on the pdp11 emulator. I attached my shell script output and the v5 image containing the v3 source code in the /sys/nsys directory. It can be downloaded here: https://www.mission-eins.de/runningv3.zip Thanks a lot and best wishes from a small suburb near Berlin, Benito Buchheim

5 years, 9 months

Re: [TUHS] Who's behind the UNIX filesystem permission

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall > it actually *unlinked* directories Maybe the application was written by a LISP programmer? :-) (Not really, of course; it was probably just someone who didn't know much about Unix. They had a list of system calls, and 'unlink' probably said ' only works on directories when the caller is root', so...) Speaking of LISP and GC, it's impressive how GC is not really a big issue any more. At one point people were even building special CPUs that had hardware support for GC; now it seems to be a 'solved problem' on ordinary CPUs. Noel

5 years, 9 months

An Excellent Unix YouTube Video

by Warren Toomey

https://www.youtube.com/watch?v=g3jOJfrOknA National Inventors Hall of Fame - NIHF Published on Feb 18, 2019 Bell Labs colleagues Ken Thompson and Dennis Ritchie developed UNIX, a multi-tasking, multi-user operating system alternative to the batch processing systems then dominating the computer industry. Not sure why I hadn't seen this before :) Cheers, Warren

5 years, 9 months

Re: [TUHS] Set-uid shell scripts

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall > Well, it's in the Subject: line :-) That was my _assumption_, but you know the old line about assumptions. Noel

5 years, 9 months

Re: [TUHS] Set-uid shell scripts

by jnc＠mercury.lcs.mit.edu

> From: Alec Muffett >>> ln -s /bin/scriptname ./-i >>> "-i" # assuming that "." is already in your path 'scriptname' (above) would have to be a shell script which was SETUID root? That was part of what I was missing, along with the below. > The cited filename is passed as argv[1] I wonder why it passed the link name, instead of the actual filename of the target (script)? Perhaps to allow one script to have multiple functions, depending on the name it was called with? But that could have been done with hard links? (Adding a hard link must require write access, because the link count in the inode has to be updated? So it would be equally secure as not having an SUID program with write access.) Part of the problem is having the kernel involved in starting shell scripts; convenient in some ways, but V6 etc worked fine without that 'feature'. Noel

5 years, 9 months

Re: [TUHS] Set-uid shell scripts

by Norman Wilson

Noel Chiappa: I wonder why it passed the link name, instead of the actual filename of the target (script)? Perhaps to allow one script to have multiple functions, depending on the name it was called with? ==== In fact the latter is still used here and there in standard system distributions. But from a security viewpoint it doesn't matter. For ln -s /bin/scriptname ./-i substitute execl("/bin/scriptname", "-i", (char *)0); If you can execute a program, you can fake its arguments, including argv[0]. There is no defence. Norman Wilson Toronto ON

5 years, 9 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