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