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 b12223a0 for ; Wed, 31 Jul 2019 18:04:11 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 562E19BA2A; Thu, 1 Aug 2019 04:04:10 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id E473894BCD; Thu, 1 Aug 2019 04:03:49 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="A1vKTBJf"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 2EE1394BCD; Thu, 1 Aug 2019 04:03:48 +1000 (AEST) Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) by minnie.tuhs.org (Postfix) with ESMTPS id 640C2949CB for ; Thu, 1 Aug 2019 04:03:47 +1000 (AEST) Received: by mail-lf1-f42.google.com with SMTP id b29so40868953lfq.1 for ; Wed, 31 Jul 2019 11:03: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=6hUb904+RabGusL/2sE+TwEOAR3aZ5ceBFUVZ+cKavU=; b=A1vKTBJfiYTDRDFvIaAwp8HApTFHgedbJgiMcdVS/GcPPWnItAmQKOHIXBNxuJb4KD yMy2lPOxT+1XIWZvlkPqBuMEHbq+1mG9HWLkwcw0gaRiGH//CyEPaG2B7NyZycq0pErE yKouvy+BwXsRJbX9bV/1NCWbJtPV/yXjTf6dtYchVea0CvJ6SXrSpfby5gWRnuLvAex1 yMrLIIieIIDXDV3tsyjR9ErHvSyvgQCIb1YZT/0vnP863/RquM87/n/HOyoZ2C43gqrw 5JHkEvuXvWFyydci+mceoxtG/kNbK+pUwtTheQ11AwpadTcYB3xUlWW7Bd5mtW39P/2S kRhA== 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=6hUb904+RabGusL/2sE+TwEOAR3aZ5ceBFUVZ+cKavU=; b=CxB4LFDlH9077lRIMgbopLLJm09mO791EMizVptFlFSW/oCmRuttO+OtQ717chyWTr WJZf2j3YsP7ELPpYvOh8lLBF/vjdbJa7V4hvwdo0qAZiDDT5DeelnKjKGpzKJ20xzSkb 094x+Mi3bWcEgCcpuCK9osoOKaTvgGUt3q+s06muvDWDnLNhitY4GSRhULImqyisbU/K 9ofkXnWSPV4tese6Az62YqZyp65bERRXrpNLXdAhQDS0OKeS3Nhf0Mbhv1XmK8Qi4Wqu mk9Q/UJPCKtSLpZXA69l3z+mWIcHNo/NTHunaS4s+wYU42EQalkn6decfb3d8CfoMpIs 8IPQ== X-Gm-Message-State: APjAAAUMFB/S2Nsf3ci1wn1kmnRRQRIlweu7uxhqeGxl7IJsUmPIDvff fM1isJwpbeceIt9IpK6/LtxDtSLIZqXq4UKY8HBIv7/g X-Google-Smtp-Source: APXvYqwVJCUYt/QOJ3it2Zm7HYF/wqSCyiWz2pYip6tdpyQoCPEEEgVA6YzDZMac7wgqu1I57k1JU+gAonq5I5BqKww= X-Received: by 2002:a19:6904:: with SMTP id e4mr40158635lfc.156.1564596225368; Wed, 31 Jul 2019 11:03:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Christopher Browne Date: Wed, 31 Jul 2019 14:03:33 -0400 Message-ID: To: Arthur Krewat Content-Type: multipart/alternative; boundary="0000000000003ae76e058efdf24a" Subject: Re: [TUHS] Who's behind the UNIX filesystem permission implementation 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: tuhs@minnie.tuhs.org Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --0000000000003ae76e058efdf24a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 31 Jul 2019 at 13:29, Arthur Krewat wrote: > On 7/31/2019 12:49 PM, Rodrigo G. L=C3=B3pez wrote: > > Multics had modes per file (https://multicians.org/fjcc4.html) but i > > don't know about the origins. the simpler approach of > > owner/group/other is a purely Unix creation and i would bet Ken > > Thompson is behind it all. > > TOPS-10 had a 3 octal digit file protection code: > > - - Logins are PPNs - [Project, > Programmer] - So if I was [76,5], another user with [76,10] was in the > same project. Much like UNIX groups. > > Owner Protection Codes > 7*, 6* - You can execute, read, or change the protection code of the file= . > 5* - You have unlimited access to the file, except for renaming it. > 4* - You have unlimited access to the file. > 3 - You can execute, read, or change the protection code of the file. > 2 - You have unlimited access to the file, except for renaming it. > 1, 0 - You have unlimited access. > * The File Daemon is called on a protection failure on this file (my > memory is a little fuzzy on this, but I believe it allowed finer grained > protections). > > Protection Codes for Fields 2 and 3 > 7 - The user cannot access the file. > 6 - The user can only execute the file. > 5 - The user can execute or read the file. > 4 - The user can execute, read, or append to the file. > 3 - The user can execute, read, append to, or update the file. > 2 - The user can execute, read, append to, update, and write to the file. > 1 - The user can execute, read, append to, update, write to, and rename > the file. > 0 - Unlimited access, including changing the protection code of the file. > > The name TOPS-10 was first used in 1970, but the monitor itself dates > back to 1964. I'm not sure when these protection codes came into being, > though. > Interesting; similar, though not identical to some material I captured back in the 1990s on TOPS-10 FILDAE in a discussion about Linux filesystem permission semantics... It seemed interesting, so I added it to a web page: linuxfinances.info/info/fs.html The claim is that there would be a fildae control file like the following: # anything in a directory named "private" is off limits */private/*:*:*:*: # people in group "foo" get full (create, delete, read, write, # execute) access to everything in the foo project directory ~/projects/foo/*:*:foo:*:cdrwx # people playing mygame can update the high score file ~/mygame/score.dat:*:*: ~/mygame/bin/mygame:rw # some friends have access to the RCS files for mygame ~/mygame/src/RCS/*:dennis,kevin,josh:*: /usr/bin/ci:rw ~/mygame/src/RCS/*:dennis,kevin,josh:*: /usr/bin/co:rw # I'll put stuff I want everyone to read in my ~/public directory # I'll make the public directory 744, so no one will actually have # to check .access_list, but I'll still put in this entry for completeness ~/public/*:*:*:*:r# anything left over gets no access*:*:*:*: --=20 When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?" --0000000000003ae76e058efdf24a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, 31 Jul 2019 at 13:29, Arthur= Krewat <krewat@= kilonet.net> wrote:
On 7/31/2019 12:49 PM, Rodrigo G. L= =C3=B3pez wrote:
> Multics had modes per file (https://multicians.org/fjcc4.html<= /a>) but i
> don't know about the origins. the simpler approach of
> owner/group/other is a purely Unix creation and i would bet Ken
> Thompson is behind it all.

TOPS-10 had a 3 octal digit file protection code:

<xxx> - <Owner, Project, Everyone else> - Logins are PPNs - [Pr= oject,
Programmer] - So if I was [76,5], another user with [76,10] was in the
same project. Much like UNIX groups.

Owner Protection Codes
7*, 6* - You can execute, read, or change the protection code of the file.<= br> 5* - You have unlimited access to the file, except for renaming it.
4* - You have unlimited access to the file.
3 - You can execute, read, or change the protection code of the file.
2 - You have unlimited access to the file, except for renaming it.
1, 0 - You have unlimited access.
* The File Daemon is called on a protection failure on this file (my
memory is a little fuzzy on this, but I believe it allowed finer grained protections).

Protection Codes for Fields 2 and 3
7 - The user cannot access the file.
6 - The user can only execute the file.
5 - The user can execute or read the file.
4 - The user can execute, read, or append to the file.
3 - The user can execute, read, append to, or update the file.
2 - The user can execute, read, append to, update, and write to the file. 1 - The user can execute, read, append to, update, write to, and rename the file.
0 - Unlimited access, including changing the protection code of the file.
The name TOPS-10 was first used in 1970, but the monitor itself dates
back to 1964. I'm not sure when these protection codes came into being,=
though.


It seemed interesting, so I added it to a web page:

The claim i= s that there would be a fildae control file like the following:
# anything in a directory named "private" is off limits
*/p= rivate/*:*:*:*:
# people in group "foo" get full (create, dele= te, read, write,
# execute) access to everything in the foo project dire= ctory
~/projects/foo/*:*:foo:*:cdrwx
# people playing mygame can upda= te the high score file
~/mygame/score.dat:*:*:
~/mygame/bin/mygame:rw=
# some friends have access to the RCS files for mygame
~/mygame/src/= RCS/*:dennis,kevin,josh:*:
/usr/bin/ci:rw
~/mygame/src/RCS/*:dennis,k= evin,josh:*:
/usr/bin/co:rw
# I'll put stuff I want everyone to r= ead in my ~/public directory
# I'll make the public directory 744, s= o no one will actually have
# to check .access_list, but I'll still = put in this entry for
completeness
~/public/*:*:*:*:r# anything left = over gets no access*:*:*:*:
--
When confronted by a difficult problem, s= olve it by reducing it to the
question, "How would the Lone Ranger = handle this?"
--0000000000003ae76e058efdf24a--