[cap-talk] More Heresey: ACLs not inherently bad

[Karp, Alan H]

Shap wrote:
>
> We are trying to run a source code repository. We have two classes of
> users of the repository: documenters and developers. We also have a
> class of administrators who determine which users are in which class
> (or
> possibly in both).
>
> The desired policy is:
>
>   1. All users in either group should have read access to all source
>      files stored in the repository.
>
>   2. In order to revise a file whose name ends in .c or .h, the user
>      must be in the developer group.
>
>   3. Similarly, in order to create a directory anyplace *other than*
> the
>      "doc" tree, the user must be in the developer group.
>
>   4. We require that every revision be able to record the principal ID
>      of the responsible revisor.
>
>   5. We require that membership of the groups be alterable, and that
>      the effect of alteration applies to subsequent attempts to revise.
>
>   6. The reference repository tree has integrity requirements that are
>      assured by guaranteeing that the data set is only updated by the
>      software configuration management server.
>
Even though I think my proposal to use capabilities for access and the ACL to implement VOC by invalidating some requests meets these requirements, I'll try again.

There is a directory tree populated with r/o capabilities to all the files.  Developers and documenters get a r/o capability to this object. (#1)  Each user gets a capability to a unique proxy that has the user's identity. (#4)   For developer's, this proxy also has a capability to a hash table mapping each r/o capability to the r/w capability for the corresponding directory, documentation, .c, or .h file. (#2, #3)  For documenters, the proxy's capability is to a hash table mapping each of the doc tree directories and each documentation file's r/o capability to the corresponding r/w capability.  Invocations are of the form myproxy.invoke(rocap, operation, list of parms).  These proxies will forward requests on the entry in the hash table if there is one and on the invoked capability if there isn't, making this solution subject to confused deputy.  (This problem can be fixed by providing a flag that lets the programmer suppress the mapping for caps passed as arguments.)  When a developer creates a new .c or .h file, a r/o capability is put in the appropriate place in the directory tree, and an entry is added to the hash table used for developers.  When a documenter creates a new documentation file, entries are put into both hash tables and a r/o cap in the directory tree.  When someone changes groups, the administrator uses a control facet on that user's proxy to change which hash table it references. (#5)

I believe that what I've described meets criteria 1-5, but I'm not sure what #6 means.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
http://www.hpl.hp.com/personal/Alan_Karp