> To boot up the root pack (I don't think I did this at any point; I've
> always mounted it as a subsidiary drive)
> ...
> The disk has a working RL bootstrap in block 0, it should boot OK.
So I recently had to reboot my machine, and I took the opportunity to try
this; it worked right off, booted 'unix' OK. (I didn't try any of the other
Unixes in the root directory.) I had only that pack mounted on DL0, nothing
else.
> So, just for grins, because I was curious (after your question), I did
> try recompiling the C compiler, to see what I'd get.
> What I got were three files (c0, c1 and c2) which were _the exact same
> size_ (down to the byte) as the binaries on the V6 Research distro, but
> had a number of differences when compared with 'cmp -l'. Odd!
> ...
> I'll take a gander tomorrow and try and work it out.
So, this turned out to be because I had replaced the csv.o in libc.a with a
new one, because the standard V6 one doesn't work with long returns (which
use R1 as well as R0, and the V6 cret bashed R1). I put the old csv.o back,
and re-linked them, and this time c? all turned out identical.
So the source in the distro really is the source for the running compiler on
it.
What was wierd was that in the new one, the routine csv is one word shorter
(and so is csv.o). So now I don't understand what made them the same sizes!?
The new ones should have been one word shorter!? Still poking into this...
I understand most of the differences between the versions of c? with the old
and new csv.o; in all the jumps to cret, the indirect word in the instruction
was off by two (because cret was one word lower because csv was one word
shorter); that, along with different contents in csv.o, created most of the
differences.
Why one word shorter? Because in csv:
tst -(sp) / creates a temporary on top of the stack
jmp (r0)
had been replaced with:
jsr pc,(r0)
(saving one instruction, and making it one word smaller).
Noel
The web page mentions files-11 which is ODS-1.
Technically (it is all coming back to me now):
FILES-11 is a family of file systems that started in RSX-11
(or perhaps before but that's the oldest instance I know).
ODS-1 is really FILES-11 ODS-1; ODS is `on-disk [something].'
RSX-11 used ODS-1. VMS used ODS-2. I'm not sure of all
the differences offhand, but they were substantial enough
that we ended up writing two different programs to fetch
files to UNIX from RSX and VMS volumes (we had the latter
to deal with too). Certainly the directory entries were
different between the two: ODS-1 used RADIX-50-encoded
file names with at most six characters plus an at-most-three-
character `extension' (a term which newbies sometimes
improperly import into UNIX as well); I forget the exact
filename rules in VMS, but filenames certainly could be
longer than six characters.
I've found the early-1980s programs I remembered. There
were two, getrsx.c and getvms.c; two programs, one for
each file-system format. They are surely full of ancient
sloppiness that won't compile or won't work right under
a modern C compiler, and they make assumptions about byte
order. I'll spend some time in the next few days going over
them and see if I can quickly get something workable.
A footnote as to their origin: in the world where we wrote
these programs, we had not only multiple systems, but
shared disk drives. The disk drives themselves were
dual-ported; the controllers we used could connect to
multiple hosts as well. Each system had its own dedicated
disk drives, but the UNIX systems could also see the drives
belonging to the RSX and VMS systems; hence the file-fetching
programs, since this was well before the sort of networking
we take for granted these days.
On the other hand, we had several UNIX systems which spoke
uucp to one another, and that was occasionally used for
large file transfers. To speed that up, I taught uucico
a new protocol, whereby control information still went over
a serial line, but data blocks were transferred over a
chunk of raw shared disk (with appropriate locks, of course).
It was a simpler world back then, but that made it a lot more fun.
Norman Wilson
Toronto ON
This is also an RSX pack (I think), but when I tried to boot it, it said
"THIS VOLUME DOES NOT CONTAIN A HARDWARE BOOTABLE SYSTEM", and since I don't
know how to mount disks under RSX-11 I left it at that.
There exists somewhere a UNIX program that reads an ODS-1 file-system
image and produces directory listings and extracts named files.
I know it exists because it was written by a friend (and probably hacked
around a little by me) almost 35 years ago, when we both worked in a
place that had some UNIX and some RSX-11. That means `somewhere'
probably includes some place in my old files. I'll see if I can
dig it out, upgrade it to work cleanly with modern C (it's just possible
I have an ODS-1 file system image lying around somewher too), and
post it either somewhere on the web or just to the list.
Norman Wilson
Toronto ON
> From: Larry McVoy <lm(a)bitmover.com>
> have you gotten to a point where you can rebuild the world and install
> your newly built stuff?
Well, I haven't tried to do that (it's not something that I'm that interested
in), but it _should_ be possible, since the 'vanilla' V6 distribution does
include the source for pretty much everything (including the C compiler,
assembler, loader, etc).
(This does not include the stuff from the Shoppa disk, like the new C
compiler, where I don't have the source. [The PWB distribution, which
includes a C compiler from 1977, is probably pretty close. Looking into
the PWB stuff is one of my next projects; we have 17 different versions
of that stuff, and I'd like to see what the differences among them are,
and maybe create a 'canonical' PWB.]
Also, per the 'Improvements' page, I have source for the Standard I/O
Library, but I'm using the binary library from the Shoppa disk, which may or
may not correspond to that source.)
Noel
Found in:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=1BSD/s6/man.c
this minor gem:
execl("/bin/ssp", "ssp", 0);
execl("/usr/bin/ssp", "ssp", 0);
printf("Can't find ssp!\n");
execl("/bin/cat", "cat", 0);
printf("or cat - gott in himmel!\n");
exit(1);
Not as good as "hodie natus" (Google it if you don't know of it - it's a
classic), but mildly amusing.
Noel
> From: Gregg Levine <gregg.drwho8(a)gmail.com>
> By Shoppa disk do you mean, Shoppe disk
The root pack (linked to from my page):
http://www.tuhs.org/Archive/PDP-11/Distributions/other/Tim_Shoppa_v6/unix_v…
It contains lots of V6 goodies - but not, alas, source for most of them. (E.g.
I had to disassemble the RL bootstrap(s) from it.)
> I've been trying to figure out how to attach them to the E11 one to
> bring the whole thing up.
The others are junk (see below). To boot up the root pack (I don't think I
did this at any point; I've always mounted it as a subsidiary drive) you'd
need to say:
mount dl0: unix_v6.rl02 /RL02
and then:
boot dl0:
The disk has a working RL bootstrap in block 0, it should boot OK. Then you
get to take your pick of which unix to boot! There are 7 to chose from:
77 -rwxrwxr-x 1 root 38598 Aug 22 1984 oldunix
77 -rwxrwxr-x 1 root 38504 Jul 19 1984 oldunix.25.7
77 -rwxrwxr-x 1 root 38568 Feb 20 1985 unix
74 -rwxrwxr-x 1 4 36956 Mar 9 1983 unix.jones
69 -rwxrwxr-x 1 root 34408 Aug 16 1983 unix.mlab
76 -rwxrwxr-x 1 4 38316 Sep 3 1982 unix.rxrl
68 -rwxrwxr-x 1 root 33958 Jun 6 1983 unix.tmp
and I have no idea how they all differ - or what each one expects to use for
a root device and swap device.
Looking at 'unix', it gives both rootdev and swapdev as '01000' (which is
probably the RL, I'm too lazy to grovel around in bdevsw and make sure). The
super block reports 19000 as the size of the file system, and sure enough,
swplo is reported as 045070 (19000), and nswap as 02710 (1480). So it's
probably set up to run and swap on RL/0.
> and any of the set of disks that are in the distributions portion of
> the site with his name on them?
All of the other disks in the V6 folder with his name on it:
http://www.tuhs.org/Archive/PDP-11/Distributions/other/Tim_Shoppa_v6
are junk; here's a brief rundown on each one:
copy_num1_user.rl02:
user0_backup.rl02:
user_backup2.rl02:
All very similar to the 'unlabeled' disk (below) - lots of random user files
for biology stuff, little if anything of any use/interest.
There is a file which isn't listed in the README:
unlabeled.rl02:
It looks like another /user disk, full of random biology stuff; nothing
interesting except a copy of a nice-looking Kermit written in C (by someone
at Columbia, IIRC).
junk:
An RL01 pack (the others are all RL02's); it has a boot block with PDP-11
code in it; I mounted it on a simulator and booted it, and it says it's an
RSX-11M V3.2 disk.
user01.rl02:
This is also an RSX pack (I think), but when I tried to boot it, it said
"THIS VOLUME DOES NOT CONTAIN A HARDWARE BOOTABLE SYSTEM", and since I don't
know how to mount disks under RSX-11 I left it at that.
scratch_disk_1123.rl02:
This does indeed seem to be something that was used for disk diagnostics: the
boot block contains gubble, including (in the first RL11 block) lots of words
with all ones, and a lot of 52525's.
Noel
>> From: Larry McVoy <lm(a)bitmover.com>
>> have you gotten to a point where you can rebuild the world and install
>> your newly built stuff?
> Well, I haven't tried to do that (it's not something that I'm that
> interested in), but it _should_ be possible, since the 'vanilla' V6
> distribution does include the source for pretty much everything
> (including the C compiler, assembler, loader, etc).
So, just for grins, because I was curious (after your question), I did try
recompiling the C compiler, to see what I'd get.
What I got were three files (c0, c1 and c2) which were _the exact same size_
(down to the byte) as the binaries on the V6 Research distro, but had a
number of differences when compared with 'cmp -l'. Odd!
I don't know what the differences result from (and it's too late now to dig
into why, I'm fading). I'll take a gander tomorrow and try and work it out.
Too bad the binaries in the Research distro have had their symbol tables
stripped! That would have made it much easier...
My guess is something like 'libraries in different order, so two library
routines are swapped around in the linked binary', or something like that
(given that the size is an exact match). But I'll need to dig a bit...
Noel
> OK, I have whipped up some material on how to bring V6 up under
> Ersatz-11. See here:
> http://ana-3.lcs.mit.edu/~jnc/tech/unix/V6Unix.html
New location (although the old one still works):
http://www.chiappa.net/~jnc/tech/V6Unix.html
So it turns out there was a bogon on the old version of this page: it claimed
the Windoze version of 'tar' needed Unix system mods (which is incorrect, it
was the version for V6 which needed the mods - cut and paste error). Fixed now
(it's useful to have a Windoze 'tar' because some of the old TAR files in the
archive can't be read by modern tools), and a certain amount of new material
added to the page overall.
> There is more content/pages coming: the start of an 'advanced things
> you can do to improve your V6 Unix' page
I've upgraded that somewhat to a complete page (although I'll probably add
more at some point in the future, e.g. I have a version of 'ps' which shows
sleep channels symbolically, text slots as ordinals, etc but I need to tweak
it a bit before I bring it out). The page is here:
http://www.chiappa.net/~jnc/tech/ImprovingV6.html
now, although the main page links to it too.
And I have another page coming, e.g. a 'what to look out for when you're
porting stuff to and from V6' guide. Etc, etc.
Noel
> From: John Cowan <cowan(a)mercury.ccil.org>
> If you haven't already, see
> <http://pdos.csail.mit.edu/6.828/2004/homework/hw5.html> et seqq.
I had seen a later variant of that course; I wasn't aware that an earlier one
used Unix; thanks for the pointer.
It's a bit unfortunate (from my PoV) that in the Unix coverage they seemed to
mostly focus on the low-level mechanics (e.g. how stacks are switched, etc,
etc), and not on the (to me) more interesting lessons to be learned from V6 -
most notably, how to get so much bang for so little buck! (I am convinced
that one of the primary challenges facing computer science these days is
control of complexity, but I don't want to get way off-topic, so I'll stop
there.)
Although I suppose things like that have to be covered at some point, and
they might as well do it in V6 as in anything else!
Noel
Hello, all: I'm working (long-term) on a project to bring back to life the
V6+ Unix system (it wasn't vanilla V6 - it looks like it had some PWB stuff
added) that was used on a number of machines at the Laboratory for Computer
Science at MIT in the late 70s - early 80s.
As part of that, I've been playing with bringing up V6 on a PDP11 simulator,
and have written some stuff that would probably be useful to anyone who's
interested in bringing up Unix on a PDP-11 simulator.
I used the Ersatz-11 simulator from D-Bit (for no particularly good reason,
except it runs under Windoze, and the "FAQ on the Unix Archive and Unix on
the PDP-11" page said it was the fastest).
I have been very pleased with this simulator; it is indeed fast (my simulated
11/70 runs at about 100 MIPS on a relatively elderly Athlon, which is about
30 times as fast as a real one used to :-), and it has lots of nice features
(e.g. you can TELNET in to a terminal port on the simulated PDP-11).
It also has this nice virtual device that allows a program running on the
simulated PDP-11 i) access to files in the Windows file system, and ii) to
issue commands to the emulator. I have written a V6 driver for it (should be
fairly easy to adapt to V7 or later), and a suite of Unix commands to grab a
file off the Windows file system (both binary and text mode), and issue
various commands to the simulator.
Finally, I have a number of Windows commands to do various useful things,
such as read a file off a simulated Unix V6 file system (hosted in a Windows
file), including ports of a number of Unix commands (e.g. ncheck, nm, etc); I
don't detail them all here as I don't want this email to get too long (and
boring).
I'm not sure if anyone's interested in any of this; if so, I can send
in more info (or whip up a Web page, whichever would be better).
I also ran into a number of pitfalls on the way to getting V6 running, using
RK05 disk images from the TUHS archive, and I can do a short writeup on 'How
to bring up V6 under Ersatz-11' if anyone's interested.
Noel
> On Sat, May 03, 2014 at 06:20:55PM -0400, Gregg Levine wrote:
> What he said. I believe we all are interested.
OK, I have whipped up some material on how to bring V6 up under Ersatz-11.
See here:
http://ana-3.lcs.mit.edu/~jnc/tech/unix/V6Unix.html
That page covers i) how to get the emulator, V6 Unix disks, and what you need
to do start it running, and then ii) some of the initial steps to take past
that to improve to working environment. Included in that are a couple of
things I tripped over, and how to avoid them.
The latter part assumes you want to do something more than just start it, so
you can see it start up; it includes coverage of the commands that work with
the emulator's "DOS device" to do things like read files off the host machine
into the Unix; a serious problem on V6 Unix having to do with 21st Century
dates; a 'more' command for V6 Unix (Vanilla V6 was back before the days of
video terminals... :-); the ability to TELNET into the emulator; and some
useful Windows commands (e.g. to read files out of the Unix into the host
machine, and create blank disk pack files); and finally configuration file
for the E11 emulator.
There is more content/pages coming: the start of an 'advanced things you can
do to improve your V6 Unix' page, which includes the new C compiler [the
'vanilla' V6 C compiler does not handle longs, unsigned, casts, and a bunch
of other things]; tar; the Standard I/O library; etc is already there, but
unfinished. And I have some material on things you can trip over in porting
stuff back and forth (I found some doozies trying to make V6 commands run
under Windoze), etc. But that will be later.
For now, I'm interested in hearing: of any errors or issues with the first
page; whether people find it completely incomprensible, or totally fantastic
(or whereever on the axis between them it lies); what additional topics I
should cover; etc, etc.
Let me know! And enjoy your V6 experience!
Noel
> From: Doug McIlroy <doug(a)cs.dartmouth.edu>
> I didn't realize that MIT had PDP-11 Unixes.
Yes; I don't know exactly when the first one arrived, but I'm pretty sure it
was around the end of my freshman year (i.e. the summmer of '75), because I
remember a friend showing me Unix sometime in my sophmore year, and they
already had it as a going concern then.
The first one (I think) at MIT was the 11/70 belonging to the Domain-Specific
Systems Research group at LCS (DSSR). I got a copy of theirs for the Computer
Systems Research group (CSR) at LCS, that would have been in the fall of '77.
I don't think the AI Lab ever had one; with us all together in 545 Tech Sq I
think I would have heard (although maybe the Turtle guys on the third floor
had one).
There were probably others on campus, but Unixes could be pretty small, and
MIT is big enough that the left hand wouldn't know of the right (and 545 Tech
Sq was kind of insulated from the rest of campus anyway). One I recollect on
main campus later on was somewhere in the EE department - maybe Speech? They
had the CHAOS protocols installed on it - that was later, say '79-'80 or so.
> Other places didn't worry about it, with John Lyons' V6 book being the
> biggest leak.
Not to mention things like the ACM paper, which was public domain...
> From: Win Treese <treese(a)acm.org>
> As I understood it, MIT's main objection was that they didn't want to
> get entangled in anything that would require students to sign
non-disclosure agreements.
That sounds likely.
> At some point, MIT did have a license with Western Electric that did
> not have such a requirement. I'm pretty sure it was at least V7, and
> possibly 32V; not sure about V6.
Well, I don't know about the license (MIT had a student who was an intern at
Bell, and I think a lot of stuff slipped out the back door with him :-), but
MIT definitely had V6 in 1976 or so, and V7 wasn't released until 1979. So we
had it long before V7. Plus to which I have listings of the kernel; it's
definitely pre-V7, but it's not vanilla V6, it has some other stuff in it (I
think it's probably PWB).
Noel
> V6 ... on a number of machines at the Laboratory for Computer
> Science at MIT in the late 70s - early 80s
Interesting. I didn't realize that MIT had PDP-11 Unixes. When
university CS departments were snapping up licenses right and
left, MIT demurred because AT&T licensed it as a trade secret
and MIT's lawyers (probably rightly) feared there was no way
they could keep Unix knowledge from contaminating research
projects. Other places didn't worry about it, with John Lyons'
V6 book being the biggest leak. AT&T lawyers did clamp down
on general distribution of the book, but Bell Labs eagerly
hired Lyons for a sabbatical visit.
Did MIT's lawyers relent by V6 time, or did LCS somehow
circumvent them?
Doug
the short: yes you could chown your own files in 1st to 5th editions, the
first pwb was a derivition of 4th ed, so its not the originator of the idea.
the long:
that "superuser could not even chown setuid files" awoke a long dead memory.
I needed to go back to read the 1st ed man entries for chown(1) and (2)
again ( see http://cm.bell-labs.com/cm/cs/who/dmr/1stEdman.html inc. below)
and it is documented that yes, one indeed could give away their
own files. also note 1st ed was pre-gid, files had only owner and
non-owner, so no setgid to worry about. looking more 2nd and 3rd ed
were the same (see ttp://www.tuhs.org/Archive/PDP-11/Distributions/research/Dennis_v2/v2man.pdf
and http://www.tuhs.org/Archive/PDP-11/Distributions/research/Dennis_v3/v3man.t…)
however in the 3rd ed there were now gids yet no restistions on chown of
setgid files. 4th and 5th ed still allowed file give away even if the
setuid bit was set by stripping that bit out (unless superuser) (but
did not strip the setgid bit)
(see http://www.tuhs.org/Archive/PDP-11/Distributions/research/Dennis_v4/v4man.t…
and http://www.tuhs.org/Archive/PDP-11/Distributions/research/Dennis_v5/v5man.p…)
The 6th ed and on is when only the superuser could change file owners.
Since the first PWBs were derived from 4th and 5th editions, they just
did not buy into the new chown() restrictions from v6 (and added the
missed strippig of the setgid bit)
1st Ed manual enries --
11/3/71 CHOWN (I)
NAME chown -- change owner
SYNOPSIS chown owner file
DESCRIPTION owner becomes the new owner of the files. The owner may be
either a decimal UID or a name found in /etc/uids.
Only the owner of a file is allowed to change the owner. It
is illegal to change the owner of a file with the set-user-
ID mode.
FILES /etc/uids
SEE ALSO stat
DIAGNOSTICS
BUGS
OWNER ken, dmr
11/3/71 SYS CHOWN (II)
NAME chown -- change owner of file
SYNOPSIS sys chown; name; owner / chown = 16.
DESCRIPTION The file whose name is given by the null-terminated string
pointed to by name has its owner changed to owner. Only
the present owner of a file (or the super-user) may donate
the file to another user. Also, one may not change the
owner of a file with the set-user-ID bit on, otherwise one
could create Trojan Horses able to misuse other's files.
FILES
SEE ALSO /etc/uids has the mapping between user names and user
numbers.
DIAGNOSTICS The error bit (c-bit) is set on illegal owner changes.
BUGS
OWNER ken, dmr
> From Doug McIlroy <doug(a)cs.dartmouth.edu>
>
> Indeed, research Unix never allowed ordinary users to
> change a uid. And even in the first edition, the superuser
> was not allowed to do so on set-uid files, presumably to
> prevent inadvertent laying of cuckoo eggs. The v6 note
> about interaction with accounting reflected field
> experience with the overly liberal stance of other Unixes.
>
On Tuesday, January 14, 2014 2:00 AM [GMT+1=CET], John Cowan wrote:
> SZIGETI Szabolcs scripsit:
>
> > Well, with the same reasoning, we don't need passwords or protection
> > bits on files, since I can always take a piece of steel pipe and
> > beat the owner, until he gives out the data, so why bother?
>
> More like beating my argument with a pipe than the owner.
>
> > Blocking chown for general users is one level of several controls.
>
> Its specific purpose was to make per-user quotas practical, but since
> per-user quotas are as dead as the dodo, it no longer serves any known
> purpose.
I don't think quotas are dead. It seems nowadays the "preferred" storage
backend for email on Unix/Linux mail servers is Maildir, and Maildir uses
the
filesystem as its own backend, together with the filesystem's quota facility
to give or take storage space to/from mailboxes -- yes, provided the users
are real system users and not "virtual users", but still.
What is "dead as the dodo" is multi-user shell access. But that does not
mean
multi-user shell access should be removed from modern systems, no matter how
dead it may be.
-Pepe.
Sorry if this is off-topic but I bet someone here will know.
I recently had a significant surprise when I discovered that on HP-UX ordinary users can still give away files. Various of us who remember fairly old Unixes then sat around trying to remember which systems had this and where it came from: getting it almost entirely wrong, it turns out.
What we remembered was that it came from BSD, but this seems to be entirely wrong. It looks like it originated with System III / V, and perhaps was imported from there into some SunOS (possibly it was in all versions before Solaris?) which is why we remember it as being in BSD. It must have been in some 80s system or we would not remember it. POSIX still allows it but clearly reluctantly.
So the questions are: (a) did it originate in System III or does it go back further than that, and (b) was it in the BSD-derived SunOSes or are we just making that up?
And I guess: who thought this was a good idea?
Thanks
--tim
Yea, but that was all much later. It wasn't a problem with PWB as it's
file system structure, in practice, was /u[0-9]/{projectname}/{username}
so when a mount point ran low on space it wasn't the individual user that
got hassled, but the projects under the mount. Makes disc usage
accounting easy too, if it's under the project, the project pays for it.
You can see that structure and how PWB was actually used by a project at
http://9grid.org.uk/pwb/users-view.pdf
> From: Ed Carp <erc(a)pobox.com>
>
> But it was fun to give away large files to someone else to avoid getting
> hassled by a sysadmin when you were close to filling up your disk quota. :)
Very, very true. PWB was all about introducing UNIX into the comp
centers which were all ready in existance, with big iron sitting
in them. Existing staff was tapped to run PWB as well, typically
consisted of operators, system administrators, system programmers,
program counselors, and accounting personal. None were researchers,
UNIX was a service to be provided, the goal was to keep the machines
up and running to charge for usage.
> From: <scj(a)yaccman.com>
>
> Recall that in those days, "systems administrator" was an entry level,
> minimum wage job. Most worked third shift, and their primary duties were
> to mount and dismount disc backup tapes. Those people who actually did
> administration in the sense we think of it were greatly underpaid and
> disrespected. The next decade or two, particularly with networking,
> caused a huge change. The Usenix LISA conferences did a lot to raise
> consciousness that there was a real there there.
>
so RJE first, yes as written it did require that chown() work as non-root,
as it ran as the "rje" euid and did chown() files to the user's uid, I do
not believe that was the cause of the chown() semantics change, just a use
of it. iOne could do the same thing by other means (run as root, have a
setuid 0, file owner changer, etc) if chown(2) was root only. Why did I
believe that?
in section V.
(iv) Make changes to the UNIX system only after much delibera-
tion, and only when major gains can be made. Avoid chang-
ing the UNIX system's interfaces, and isolate any such changes
as much as possible. Stay close to the Research UNIX system,
in order to take advantage of continuing improvements.
OK now lets look at a passage from VI --
A good many UNIX (as opposed to PWB/UNIX) systems are run
as "friendly-user" systems, and are each used by a fairly small
number of people who often work closely together. A large frac-
tion of these users have read/write permissions for most (or all)
of the files on the system, have permission to add commands to
the public directories, are capable of "re-booting" the operating
system, and even know how to repair damaged file systems.
The PWB/UNIX system, on the other hand, is most often found
in a computer-center environment.
So the old way, no one even really needs chown() everybody had access to
everything.
then 8.1
The first major set of reliability improvements concerned the
handling of disk files. It is a fact of life that time-sharing sys-
tems are continually short of disk space;
...
long-term tape backup copies, on the other hand, offer users the
chance to delete files that they might want back at some time in
the future, without requiring them to make "personal" copies
disk is always full, and users are discourged from making multiple copies
of f and even encourge to remove stuff you do not need right now and get
it from backup later, let alone making copies of someone else's files.
next from 8.4, while its abouttrying to solve the uid shortage
(only 256 at the time) it shows you the users' mind set, groups tended to
functionally operate as single user, but everyone still wanted a unique id.
.... depended heavily on the
characteristics of the PWB/UNIX user community, which, as mentioned
above, consists mostly of groups of cooperating users,
rather than of individual users working in isolation from one
another. Typical behavior and opinions in these groups were:
(i) Users in such a group cared very little about how much
protection they had from each other, as long as their files
were protected from damage by users outside their group.
(ii) A common password was often used by members of a
group, even when they owned distinct user-IDs. This was
often done so that a needed file could be accessed without
delay when its owner was unavailable.
(iii) Most users were willing to have only one or two
user-IDs per group, but wanted to retain their own login names
and login directories. We also favored such a distinction, because
experience showed that the use of a single login name by
more than a few users almost always produced cluttered
directory structures containing useless files.
so the group members would know each othesr passwords (but there were many
groups on the same machine) thus non-root chown() become self-service in
sharing of files between group members, without the need of system
administrator involvment. while one could give their files to someone
outside the group, it is not productive.
And then --
to improve the security of files, a few commands were
changed to create files with read/write permission for their own-
ers, but read-only for everyone else. The net effect of these
changes was to greatly enlarge the size of the user community
that could be served, without destroying the convenience of the
UNIX system and without requiring widespread and fundamental
changes
shows the need to lock down file access, which means if you are sharing
in Research UNIX you did not need to chown() files, you could
just write them, but PWB will lock it down so a different group cannot
muck with it.
Now you are going to say this could all be done with proper use of group ids
and group permissions. I agree, but in practice it was not done, as PWB
even consdidered the complete removal of gids, but only decided against it
as they would have to change too much software --
considered was that of
decreasing the available number of the so-called "group-IDs," or
removing them entirely, and using the bits thus freed to increase
the number of distinct user-IDs. Although attractive in many
ways, this solution required a change in the interpretation of
information stored with every single disk file (and every backup
copy thereof), changes to large numbers of commands, and a fun-
damental departure from the Research UNIX system during a time
when thought was being given to possible changes to that
system's protection mechanisms. For these reasons, this solution
was deemed unwise.
> From: Clem Cole <clemc(a)ccc.com>
>
> Brian - I know the paper and Mash - the 3rd author and lived the times ;-)
>
> I just don't see how having the ability to give away a file to some one
> else made it easier for anyone - system programmer or admin. The idea of
> giving a device back begs the question of how did you get ownership in the
> first place.
>
> The one thing I could think of was something like the RJE system that you
> would wanted to have made your files be owned by the RJE system, have them
> send it to the mainframe, get back information and then give the results
> back to you. If they wanted to do that subsystem with out a root style
> privilege, you would need some way to give files away.
>
> But I can think of other ways to do that without needing the chown(2) call
> to work with that semantic, so I really don't understand what it was used.
>
> To me, it does not seem to be worth much. As I said have to ask Mash if
> he remembers why it was considered a good idea.
>
> Clem
Yep, but where did the user base from PWB come from? They were
existing professional programmers from the mainframe world, still
writing for the mainframe, now sumbmitting via UNIX RJE.
Where did the sysadmins of PWB that added these users come from?
Same answer. If users are not added into the right groups, and
the users don't know (or need, care, or be able change) groups,
they don't get implemented properly.
And if you don't have gids, want to collaborate, and are discouraged
from copying, you need to do a ton of chown()s
> From: Larry McVoy <lm(a)bitmover.com>
>
> > Now you are going to say this could all be done with proper use of group ids
> > and group permissions. I agree, but in practice it was not done
>
> Bzzt. We have a solution, they should have used it.
>
it follows the philosophy of pwb -- a usable system for disparate small groups
of developers on the same hardware that could be managed by admins not
system programmers.
read http://www3.alcatel-lucent.com/bstj/vol57-1978/articles/bstj57-6-2177.pdf
for the flavor of that time, and you'll understand better.
> From: Clem Cole <clemc(a)ccc.com>
>
> Brian - right as I showed in the code snippet from V6 and PWB. The idea
> came into being with PWB.
> The question that is still open is why was it added/need in the first
> place? I always thought is was a crazy/miss feature,
>
> I think the argument is that if you owned the file, you should be allowed
> to give it to anyone else [including root] - but that actions opens up a
> number of issues (you pointed the big security one that was handled by
> and-ing off the SUID/SGID bits). There are accounting issues as well as
> the practical one that Tim and I pointed out with importing of files on a
> tape.
>
> As I said, the file give-away feature comes into UNIX with PWB, so I would
> ask Mash is he remembers why it was needed and why the SVID folks wanted
> it. As I said, I personally found it not useful/a bad idea/miss-feature.
> I remember that I soon after I learned about it/got bitten by the side
> effect, I ran into dmr and srb at a USENIX and asked them about that a few
> other System III features that I found a little strange. I don't remember
> much of the conversation. But, if there are been a "good" reason I think
> I would have remembered it and not always thought it to be a bad idea.
>
> Clem
Indeed, research Unix never allowed ordinary users to
change a uid. And even in the first edition, the superuser
was not allowed to do so on set-uid files, presumably to
prevent inadvertent laying of cuckoo eggs. The v6 note
about interaction with accounting reflected field
experience with the overly liberal stance of other Unixes.
non-su chown worked in pwb, if the caller owned the file. code had to be
added then to the system call to strip the setuid/setgid bits if you were
not su, for obvious security reasons. you didnt see that bit stripping
in, say the v6/v7 code.
> From: Tim Bradshaw <tfb(a)tfeb.org>
>
> Sorry if this is off-topic but I bet someone here will know.
>
> I recently had a significant surprise when I discovered that on HP-UX ordinary users can still give away files. Various of us who remember fairly old Unixes then sat around trying to remember which systems had this and where it came from: getting it almost entirely wrong, it turns out.
>
> What we remembered was that it came from BSD, but this seems to be entirely wrong. It looks like it originated with System III / V, and perhaps was imported from there into some SunOS (possibly it was in all versions before Solaris?) which is why we remember it as being in BSD. It must have been in some 80s system or we would not remember it. POSIX still allows it but clearly reluctantly.
>
> So the questions are: (a) did it originate in System III or does it go back further than that, and (b) was it in the BSD-derived SunOSes or are we just making that up?
>
> And I guess: who thought this was a good idea?
>
> Thanks
>
> --tim
OK, let me try this one more time with links to get around the
restrictions on the message size.
I was cleaning out my basement and I
found a box of stuff from my office at BRL (where I left in 1987).
Most
of it was buttons I'd picked up at trade shows and SF cons (I had a
fabric partition next to my desk that I had them all stuck to.
Of
course in the box (among a couple of later editions) was Armando's
original UNIX license (note no reference to DEC):
Also in the box were
some buttons from various UNIX conferences. I particularly remember the
Sex, Drugs, and Unix one. Some of you will also remember the year I was
giving out the No Ada shirts. There's a picture of dmr wearing one
floating around somewhere.
Sun was giving out these one year:
Peter
Langston thought this was a little conceited on Bill Joy's part, so the
next show he arrived with buttons to hand out that said things like "The
psl of UNIX" and "The dmr of UNIX". I had a "The ron of UNIX" somewhere
but I couldn't find it in the box.
Finally there was this wooden
nickle courtesy of Bill Yost...
