On 2019-07-31 5:59 a.m., Stephan Han. wrote: It may not address "all aspects" since it has been necessary for some purposes to extend the permission model substantially over time, such as ACLs, SELinux, etc. --Toby

On 7/31/2019 12:49 PM, Rodrigo G. López wrote: TOPS-10 had a 3 octal digit file protection code: <xxx> - <Owner, Project, Everyone else> - 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.

On Wed, 31 Jul 2019 at 13:29, Arthur Krewat &lt;krewat(a)kilonet.net&gt; wrote: 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*:*:*:*: -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"

On Wed, Jul 31, 2019 at 2:46 PM Grant Taylor via TUHS &lt;tuhs(a)minnie.tuhs.org&gt; wrote: It's really how strict you want to be in the definition of an ACL. UNIX uses the same basic/simple model but traditional UNIX style ACLs of 3 options of 3 modes are implemented are just more coarsely defined than say VMS or later NT or SELinux, uses for their file systems. It's arguable that the extra granularity of the others actually adds a great deal in actual day to day use cases. At one time, I will admit that I had thought VMS style ACLs might be more helpful to UNIX and we added them to one of our file systems, but when I look back on 40 years of using anything beyond UNIX style ACLs its been pretty rare when I actually needed much more (*i.e.* theory vs. practice). The problem is the programming interface tends to get more difficult when you add some of the extra features. To me the brilliance to UNIX has always been getting down to a very simple interface that was "good enough" to get the *job done* and not so full of *extra stuff *that it gets in the way (which tends to be a complaint by way with Linux -- which does have a lot of new/rich features, but so full of some many different features theses days you have to wonder is/was it worth it). To me, it's arguable that ACL's beyond R/W/E and U/G/E is really needed in practice. Clem

Sorry to reply to myself, but I wanted to add one note to this, and didn't, which pertains to the "rename" versus "update" part of file protections in TOPS-10, and perhaps was a bug that was never fixed, or it was, and I didn't know it. In TOPS-10, you use the monitor call ENTER to update (write to) an existing file. It uses a common argument list with LOOKUP and I think a few other calls, that include the file name and extension. If a file had a 4 protection code for you, you could LOOKUP the file, then ENTER it with a different filename, and the filename would change, effectively renaming the file which you would think required a 1 protection code. You could also, if I recall correctly, specify a different protection. The significance of this? Many installations put files in SYS: ([1,4]) that had a 4 protection code so they could be written to by various applications users ran, or it was an oversight by a system administrator. Using DDT, one could easily whip up a short piece of code to rename any file in SYS: that had a 4 protection code, rename it to a .SAV or .SHR (if it needed a highseg) and basically "hide" behind another program, such as LOGIN.EXE (When EXE was introduced, I think in version 6, TOPS-10 still supported .SAV, .SHR, and .HGH but would attempt to run the .EXE first if you didn't specify an extension). Certain programs in SYS: like LOGIN had JACCT privileges - full rights to everything, including device I/O. So, find a writable file in SYS:, rename it to LOGIN.SAV, copy PIP over it, or something you cobbled up yourself, and take over the system without causing any other issues except that missing writable file. JACCT priv was much like "setuid" in UNIX - except it was a hardcoded list of filenames in the monitor (I think mostly or exclusively in SYS:) that would get carte blanche access to everything. I believe by version 7, some programs had been deprecated out of SYS, but they still existed in the JACCT list in the monitor. And boy, there were a lot of systems out there on Telenet or the ARPANET that had files in SYS: protected with a 4. Side note: Telenet was BBN's attempt to create a private sector ARPANET. https://en.wikipedia.org/wiki/Telenet - A late night dumpster dive at Radio Shack in the very early 80's got me a local dialin number. Sorry for the lengthy dissertation :) On 7/31/2019 1:29 PM, Arthur Krewat wrote:

The "useful layer of indirection" story carries the seeds of its own problem, if you consider xattr on files. They always prove harder to deal with, lie in cat -v extended options, cannot be invoked without bigger wetware cache memory than I hold, which requires a retreat to the man page, and crop up at the worst possible times, such as when you are doing buildworld installworld sequences, they blow up, and you have xattr locked files with setuid bit littering the FS tree. chmod can't do them with octal bit settings or they lie in octal spaces I don't understand further up from 777 Necessary but evil. What I like about user/group/other is that the group memberships list is independent, but maps into the tested space in the flags for chmod. If I want to grant somebody permission in group sense, I make sure we share a group and I arrange for the group to be set. If I cannot make the dir be group the same, I use --x permissions on other to give them transitive rights down into the file. It would be possible to argue creat(e) was a distinct permission from write. I think I heard Dennis say he regretted some aspects of the model around "is write the same as create" at an AUUG once, (I mean more than just his joke about calling it creat() not create() -he actually said there were arguments both sides to breaking out more modes of behaviour on things, and modifying the contents of a created named entity is not the same as naming it) And Microslop and xattr and I think VMS do indeed go to the "I can make things as well as change things" place. So yes, write permissions on the directory are the "proper" place to say "you can make things" but then you're in an indirection: the dir block is not the file, the file name is in the dir block, oh dear, so maybe we mean we want Apples resource fork and the data fork, a model I could never understand? No please.. but.. then again.. Oh dear. Its just a projection into a UNIX FS to make this a file and a .attr file, thats not how Apple "Ideated" it, but still. All designs come with costs. I guess if you like apple pie, you can dream about peaches, but peaches aren't apples. On Thu, Aug 1, 2019 at 8:36 AM William Corcoran &lt;wlc(a)jctaylor.com&gt; wrote: