FWIW: Before TOPS, there was MIT's CTSS. The DEC Project, Programmer Number (a.k.a. PPN) idea seems to have been similar to the People and *Problem Number* idea of CTSS, which allowed for directories of your own files and as well as your group (shared problem number). As Rodrigo pointed out Multics also had a form of ACLs (UNIX used ACL's just very simplified ones). So I'm not sure where to pin this specific idea. I think it was a bit like a lot of CS ideas, different people were playing with different aspects of different ideas at the time, and brillance of Ken and Dennis was putting some of the *best ideas *of the day *together* and adding a few of their own into a simple implementation that was good enough to do real work. Clem On Wed, Jul 31, 2019 at 1:29 PM Arthur Krewat <krewat(a)kilonet.net> wrote:

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:

On Wed, Jul 31, 2019, 12:09 PM Toby Thain <toby(a)telegraphics.com.au> wrote: He did say they solved the problem without hassle. All those other things introduced hassle. :) There is also all the various capacity frameworks to self limit what you are allowed to do as any easy to administer exploits... Warner --Toby

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 <wlc(a)jctaylor.com> wrote:

On Wed, Jul 31, 2019 at 2:46 PM Grant Taylor via TUHS <tuhs(a)minnie.tuhs.org> 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