The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Clem Cole <clemc@ccc.com>
To: Aharon Robbins <arnold@skeeve.com>, Doug McIlroy <doug@cs.dartmouth.edu>
Cc: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: Re: [TUHS] Additional groups and additional directory permissions
Date: Fri, 2 Aug 2019 09:28:18 -0400	[thread overview]
Message-ID: <CAC20D2PwOxA4LGo+YFt7dLy1kmaQq_cnptYuy8Ajd6ajBqFcPg@mail.gmail.com> (raw)
In-Reply-To: <201908020835.x728ZUal026532@freefriends.org>

[-- Attachment #1: Type: text/plain, Size: 2336 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3788 bytes --]

  parent reply	other threads:[~2019-08-02 13:29 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-01 12:35 [TUHS] Who's behind the UNIX filesystem permission Doug McIlroy
2019-08-01 16:22 ` John P. Linderman
2019-08-01 16:35   ` Arthur Krewat
2019-08-02  8:35   ` [TUHS] Additional groups and additional directory permissions arnold
2019-08-02 11:18     ` Tony Finch
2019-08-04  6:40       ` arnold
2019-08-02 12:45     ` Arthur Krewat
2019-08-02 13:06     ` Clem Cole
2019-08-02 13:28     ` Clem Cole [this message]
2019-08-02 19:00       ` Thomas Paulsen
2019-08-01 17:01 ` [TUHS] Who's behind the UNIX filesystem permission Nemo Nusquam
2019-08-01 18:26   ` Arthur Krewat
2019-08-01 20:14     ` Lyndon Nerenberg
2019-08-01 21:23 ` Dave Horsfall
2019-08-02 19:44 [TUHS] Additional groups and additional directory permissions Norman Wilson
2019-08-10  4:02 Kirk McKusick
2019-08-10  6:02 ` Thomas Paulsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAC20D2PwOxA4LGo+YFt7dLy1kmaQq_cnptYuy8Ajd6ajBqFcPg@mail.gmail.com \
    --to=clemc@ccc.com \
    --cc=arnold@skeeve.com \
    --cc=doug@cs.dartmouth.edu \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).