Path: utzoo!utgpu!watmath!clyde!ima!think!barmar From: barmar@think.COM (Barry Margolin) Newsgroups: comp.arch Subject: Multics (was Re: Operating Systems (Re: archimedes)) Message-ID: <32541@think.UUCP> Date: 2 Dec 88 21:28:42 GMT References: <12633@steinmetz.ge.com> <6191@killer.DALLAS.TX.US> <12655@steinmetz.ge.com> <343@maxim.ERBE.SE> Sender: news@think.UUCP Reply-To: barmar@kulla.think.com.UUCP (Barry Margolin) Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 27 In article <343@maxim.ERBE.SE> prc@ERBE.SE (Robert Claeson) writes: >Maybe all permissions should be set on the object (ie, file system entry) >it protects, so that a file has read, write, execute, delete, and append >permissions, rather than giving delete permissions for files at the >directory level (write)? Yes, this sounds much like VMS, Multics, etc, >but those OS'es has their good spots... I don't know much about VMS, but Multics's access control rules are pretty much the same as Unix's, except that it has access lists rather than just user/group/other. But the only modes are read, write, and execute (except for inner-ring files, which can have any modes that the gate wishes to implement). It even has the same rule that anyone can delete a file if they have modify access to the directory. The only significant difference is that Multics directory permissions are status (ability to list the directory and get properties of the entries contained therein), modify (ability to modify properties of or delete entries in the directory), and append (ability to create new entries). This allows us to create directories in which anyone can add new entries, but not modify or delete existing entries (similar to the versions of Unix that have sticky mode on directories). Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar