Text File

Aucbvax.4571 fa.unix-wizards utzoo!decvax!ucbvax!unix-wizards Wed Oct 21 03:06:44 1981 Why one does NOT want access lists (in files). >From walton@LL-XN Wed Oct 21 02:35:50 1981 There are at least two kinds of file protection system. One, which I call the work oriented one, associates a single lock with each file and a list of keys with each process. It aims to ensure that people get their work done smoothly with little bother from the protection system. The major sin in this philosophy is for a legitimate user to be thwarted by the protection system: so the emphasis is on making sure that everyone who needs a key has it, without going overboard.

The other, which I call the security oriented one, associates one user id with each process and a list of user id's with each file. This is appropriate to a real security system with strict monitoring of file access, with only users with a need-to-know having access, etc. The last thing you want to do is group users together in such a system.

The latter system is what I think of as an access list system, like something Ken Thompson talked about adding to UNIX years ago, with an access list for each file. MULTICS apparently has such a system. I suppose the former system might also be called an access list system, but I am not used to it being called such. Do not know quite what to call it, frankly. A lock-and-key list system maybe. The idea is that the locks are dumb, like real world locks, whereas a file access list is a smart lock.

This latter system is not that appropriate for UNIX, except for KSOS, NSA's attempt to make a version of UNIX suitable for use in a real security environment. Its too easy to lose control of security in other ways in UNIX. The first system is work oriented because it is easier to maintain keys than locks, since each user deals with only one user but many files, so a system with dumb easily maintained locks on the files and smart lists of keys is easier to work with than a system with smart locks and dumb keys.

I have an interesting hypothesis to the effect that there is no real use for a system that maintains a list of group id's with the process and another with the file's and attempts a full matrix match. I.e., it is sufficient to have smart keys interacting with dumb locks and smart locks with dumb keys, but not have any interaction between smart keys and smart locks.

Of course everything is an efficiency matter in the end, since either of the above systems can be used to emulate the other, but with such poor efficiency and bad user confusion that one would not want to do it very much.

I find this is my third missive on this subject in a few days: one proposal and two responses. I am going to try the combined strategy of accumulating public responses and responding in appropriate cases only to individuals in order to reduce this rate. Unfortunately, while proposals in this area are often simple, analysis of the requirements placed on such a system is not, so I hope the rest of you will tolerate me if I invite debate for a little while longer.

----------------------------------------------------------------- gopher://quux.org/ conversion by John Goerzen <jgoerzen@complete.org> of http://communication.ucsd.edu/A-News/

This Usenet Oldnews Archive article may be copied and distributed freely, provided:

1. There is no money collected for the text(s) of the articles.

2. The following notice remains appended to each copy:

The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 Bruce Jones, Henry Spencer, David Wiseman.