The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: "John P. Linderman" <jpl.jpl@gmail.com>
To: Doug McIlroy <doug@cs.dartmouth.edu>
Cc: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: Re: [TUHS] Who's behind the UNIX filesystem permission
Date: Thu, 1 Aug 2019 12:22:35 -0400	[thread overview]
Message-ID: <CAC0cEp8oZ6kYXZGrwSVKM64MdkKCEMnkwu_62k9z+bne9x-Gaw@mail.gmail.com> (raw)
In-Reply-To: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU>

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

*Yet clean as the idea of groups was, it has been used only sporadically
(in my experience).*


As I recall it, the original "basic groups" were essentially "us" and
"them". "Us" was everyone in the "in crowd", "them" was everyone else.
Since the basic groups were rather extensive, it was prudent to turn group
write permission off in your default umask. But that made groups rather
clunky. You were in only one group at a time, so you had to "chgrp" to a
select group, and then remember to set your umask to allow group write
permission so others in the group could modify files. This changed when you
could be in multiple groups at the same time (a BSD invention?), and your
primary group automatically changed to the group owning your current
working directory (iff you belonged to that group). This made it
unnecessary to do an explicit chgrp in most cases. Having group write
permission off in your default umask was now a nuisance. We fixed that by
giving everyone an unshared primary group id, typically the same as the
uid. It then became safe to make group write permission on by default. This
made groups much more useful. Anyone in a group (but only those members)
could create a directory owned by that group, and group members working in
that directory defaulted to creating files (and subdirectories) group-owned
by and writable by all the members of the group. It just worked.

On Thu, Aug 1, 2019 at 8:36 AM Doug McIlroy <doug@cs.dartmouth.edu> wrote:

> Read and write permission were common ideas--even part of
> the Atlas paging hardware that was described before 1960.
> The original concept of time-sharing was to give a virtual
> computer to each user. When it became clear that sharing
> was an equally important aspect, owner/other permissions
> arose. I believe that was the case with Multics.
>
> Owner/other permissions were in PDP-11 Unix from the start.
> Group permissions arose from the ferment of daily talk in
> the Unix lab. How might the usual protections be extended
> to collaborative projects? Ken and Dennis deserve credit
> for the final implementation. Yet clean as the idea of groups
> was, it has been used only sporadically (in my experience).
>
> Execute permission (much overloaded in Unix) also dates
> back to the dawn of paging. One Unix innovation, due to
> Dennis, was the suid bit--the only patented feature in
> the Research system. It was instantly adopted for
> maintaining the Moo (a game now sold under the name
> "Master Mind") league standings table.
>
> One trouble with full-blown ACLs as required by NSA's
> Orange Book, is obscurity. It is hard (possibly NP-
> complete) to analyze the actual security of an ACL
> configuration.
>
> A common failing of Unix administration was a proliferation
> of suid-root programs, e.g. mail(1). I recall one system
> that had a hundred such programs. Sudo provided a way
> station between suid and ACLs.
>
> Doug
>

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

  reply	other threads:[~2019-08-01 16:23 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-01 12:35 Doug McIlroy
2019-08-01 16:22 ` John P. Linderman [this message]
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
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-01 23:43 Noel Chiappa
2019-08-02  1:03 ` David Arnold
2019-08-02  4:36   ` Rob Pike
2019-08-07  2:35 ` Dave Horsfall
2019-08-02 14:35 Noel Chiappa
2019-08-02 15:01 ` Clem Cole
2019-08-02 15:17 ` Arthur Krewat
2019-08-02 21:23   ` Dave Horsfall
2019-08-03 12:51     ` Nemo

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=CAC0cEp8oZ6kYXZGrwSVKM64MdkKCEMnkwu_62k9z+bne9x-Gaw@mail.gmail.com \
    --to=jpl.jpl@gmail.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).