Inheritance

Essentially, Multics supports 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 object and right 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 grouped based on their type (the IS-A relationship) or their structure (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.

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 can use 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

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) 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).

AFS partially supports object 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, since one cannot change the rights of a specific file. (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.

NTFS, on the other hand, actually supports true object inheritance Thus, if we create a child directory, and then remove the Write right from the parent directory, we cannot create new subdirectories in the parent or child directory. We can now add the Write right to the child to allow sub directories in the child but not parent directory.

It also supports of right groups. For example FullRights inclused all other rights that can be specified explicitly such as Write and Read plus administer rights. However, it is not possible to give (take away) a right group and take away (give) a member of the group. For example, it is not possible to take away the FullRights right and give the Write right. Taking away the FullRights right implies taking away all the member rights.

This restricted form of inheritance may have been prompted by the need to reduce the multiple inheritance problem - each inheritance mechanism provides another way to make default specifications - which default should be used.

One approach is to require strong inheritance, which says the system will not allow multiple conflicting default specifications to be made. Weak inheritance allows multiple default specifications. NT supports weak inheritance. It is possible for a specific user to inherit from multiple groups, and it is possible for a directory to inherit from its parent. To illustrate, assume the following specifications are made:

proj1, students, +W
projects, RAs, -W

where, proj1 is a subdirectory of projects, and RAs is a subgroup of students. Now suppose Sasa, a member of RAs, tries to access main.c, a file in proj1. If we follow the directory inheritance chain, we find the first access definition, which is associated with the structural parent of object main.c. The specification says that Sasa and other students get Write access to the file. On the other hand, if we follow the user inheritance chain first, we encounter the second defintion, which is associated with the parent group of user Sasa. It says that Sasa (and all other RAs cannot) access the file or any other descendent of the projects. Neither definition is more specific than the other - the first applied to a more specific object group but a more general user group while in the second case, the reverse is the case. Thus we must make an arbitrary choice between them. In NTFS, the object inheritance link is considered primary, and the user inheritance link is considered secondary, so the first choice above wins.

We resolved the inheritance problem above by giving prorities to the different types of inheritances defined by different relationships. What if the same type of inheritance occurs along multiple paths. For example, in NTFS, a user can belong to multiple groups, thereby creating multiple inheritance paths based on the same relationship: IS-MEMBER-OF-USER-GROUP. In NTFS, all paths defined by this relationship are examined, and the most conservative inherited right is chosen. Thus, if one user group denies a right and another one gives it, the former is chosen. One can imagine a dual, more permissive policy, which gives the most liberal right.

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.