TUHS August 2019

tuhs@tuhs.org

64 participants
36 discussions

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, 4 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, 4 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, 4 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, 4 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, 4 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, 4 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, 4 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, 4 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, 4 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, 4 months

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 August 2019