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