Essentially, Multics is supporting inheritance in the subject dimension, that is, it allows access specifications made for groups of subjects to be inherited by members of the group. One may want to also support inheritance in the objects and rights dimensions.
In the case of the object dimension, we can allow access rights to be associated with groups of objects, which apply to all members of the group that do not override them. Objects can be based on their type (the IS-A relationship) or their structure (the IS-PART-OF). For instance, we can give the Append right to all objects that are of type Bibliography unless a specific instance overrides it. Similarly, we can give the Write right to all objects (files/directories) in a particular directory unless a particular object overrides it.
AFS partially supports such inheritance - in the context of access lists. It associates a directory with both file rights and directory rights. The file rights apply to all files in the directory. Moreover, when a new directory is created, it gets a copy of the (file and directory) rights of its parent. Thus, the file and directory rights specified for a directory apply to all of its descendents.
This approach is not true inheritance, however,
(AFS reduces this problem by looking at both the Unix file rights associated with a file and the AFS file rights associated with the containing directory. Access is allowed only if both sets of rights allow it. In the case of Unix rights, only the owner rights are examined. Again this is not true inheritance and is more a hack for backward compatibility with Unix.) Moreover, a directory does not truly inherit the rights of its parent in that if the rights of the parent of a directory are changed, the rights of the children directories are not changed, even if no explicit access specifications have been made for these directories.
What about the right dimension, does it make sense to apply one access definition to multiple rights? Consider the Write right. If a subject can write to an object, he can also insert into it. Thus, it should not be necessary to give insert rights to subjects once write rights have been given. We have used the imply relationship here to reduce the number of access definitions that have to be made and stored. Some potential imply relationships are: Write => Insert => Read => Append Create Group => Add Member
Note that implication and inheritance are similar in that one access definition applies to multiple cases. However, the latter does not support overriding. It is semantically inconsistent to give the Write right but not the Insert right to a subject.
We can also consider inheritance in the right dimension. We can group the rights into right groups such as Object Rights (Write, Read, Append, Insert, Execute) and Administration Rights (Modify Rights, Set Owner, Create Group, Add Member). We could then give a subject (group) as all rights in a right group to an object (group). For instance, we can give all members of the 242 group all Data Rights to all objects in the directory 242notes. An access definition specifying a more specific right (Write) can then override one specifying a more general right (Data Rights).
We now have the multiple inheritance problem - that is, one may inherit conflicting definitions from different sources. This problems is, in general, hard to resolve in an elegant way and we will not consider it any further.
All kinds of inheritances can be supported by both access lists
and capability lists.
In particular,
object inheritance is a powerful way
to reduce the problem of long capability lists.
One can store only entries corresponding to groups of objects rather than
individual objects.
This is analogous to storing entries corresponding to groups of users in
access lists.