From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id f03eb733 for ; Thu, 1 Aug 2019 16:23:25 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 9A3A09BA32; Fri, 2 Aug 2019 02:23:24 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 0DFDA94903; Fri, 2 Aug 2019 02:22:50 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="AsY11f7J"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 6911C94903; Fri, 2 Aug 2019 02:22:48 +1000 (AEST) Received: from mail-ua1-f51.google.com (mail-ua1-f51.google.com [209.85.222.51]) by minnie.tuhs.org (Postfix) with ESMTPS id ADADC948EB for ; Fri, 2 Aug 2019 02:22:47 +1000 (AEST) Received: by mail-ua1-f51.google.com with SMTP id 8so28563923uaz.11 for ; Thu, 01 Aug 2019 09:22:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mh7AmdJwy0ypXNRhMteznUWAPInmz2s+zgibhakIP4g=; b=AsY11f7J1KM6np4UawE64UF96OY1g00NqQXmN5r5GAdqcvyXxruW5Oasnnhw+TRLCR m0L3Yy91gXihCce6+rE8N2KeWwSnc6asmtKH3nlJPmAsENVMSb2wn+o3Ll0JDy3qysnS 854egkj7E/b3i1zFqo7mnyg/siGIaPXEDp35fCqWrF9WdxvHtRSu7+SxVfa2exD4YZUa 7xmWtUjBTi7+XV7PXVVfPJi5A4wvxh47eBUFZ9x1rCN3Js3VzKK5ueoBE1qazMhgUuKG ITTrBXXZN36DfZgpKY2dc49TPn3U30t5UrJNR7wQG6ZVYrZ8AJTBA0OQbwwDV6XCYRaN Tlxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mh7AmdJwy0ypXNRhMteznUWAPInmz2s+zgibhakIP4g=; b=qm/A1ZQN9Vm5kIi0HvNlu86kwQZVN/aaYMFswdIeVlJif/ddpAWyljMchUINj0x2pY aNIUJOxCd1D++FEay09NfJgZLPbZ+15Mdd5nPXFRy5I9XR1juJwq5qF0/1kI/v3/xmUp RXcu2X1yQhf27CWkooVGyIZDLoZIuKYo/spYobup+AW+vWSljB6uKphfgvF1IieevLUp 0HDwKT4itZBd1wIlJTsELxlMl5Vr6TMIPrOFqBotXAsSSAPHFzgAbgGbWtGXha3tZuio aVWLaJ5+ncixGaW/NLuVoYSPfXzo3/0a9WfSZdaGpaAJPFqZrsPMsel6nvtBN6wYj4Hp 9ztg== X-Gm-Message-State: APjAAAUjRhv+7Qdii2t3ThL/CDiMBy1tc6POvE4q+BpCNwTzkIH0azhN YJEvMZDUznOH7LNKFvTtvvBUyRUMlM/JzP/xln4= X-Google-Smtp-Source: APXvYqzO/2BzQ2Gkktxnj8NpK77Ptdb+cZu5+0iKh3dImqdNmUZRp94xS8IimgLnAsRzewkqNq95b6jC5Uu42R1h3GY= X-Received: by 2002:ab0:74c7:: with SMTP id f7mr24283346uaq.106.1564676566616; Thu, 01 Aug 2019 09:22:46 -0700 (PDT) MIME-Version: 1.0 References: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU> In-Reply-To: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU> From: "John P. Linderman" Date: Thu, 1 Aug 2019 12:22:35 -0400 Message-ID: To: Doug McIlroy Content-Type: multipart/alternative; boundary="000000000000f11064058f10a668" Subject: Re: [TUHS] Who's behind the UNIX filesystem permission X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: The Eunuchs Hysterical Society Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000f11064058f10a668 Content-Type: text/plain; charset="UTF-8" *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 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 > --000000000000f11064058f10a668 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yet clean a= s the idea of groups was, it has been used only sporadically (in my experie= nce).

As I recall it, the original "basic groups&quo= t; 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 clu= nky. 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 yo= u could be in multiple groups at the same time (a BSD invention?), and your= primary group automatically changed to the group owning your current worki= ng 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 yo= ur default umask was now a nuisance. We fixed that by giving everyone an un= shared 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 u= seful. 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 t= he members of the group. It just worked.

On Thu, Aug 1, 2019 at 8:36 = AM Doug McIlroy <doug@cs.dartmo= uth.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
--000000000000f11064058f10a668--