The basic purpose of NIS+ authorization is to specify the access rights that each NIS+ principal has for each NIS+ object and service.
Once the principal making an NIS+ request is authenticated, NIS+ places that principal in an authorization class. The access rights (permissions) that specify which operations a principal may do with a given NIS+ object are assigned on a class basis. In other words, one authorization class may have certain access rights while a different class has different rights.
NIS+ objects do not grant access rights directly to NIS+ principals. Instead, they grant access rights to four classes of principal:
See the following figure for an illustration of the classes.
Figure 7-3. Authorization Classes. This illustration shows a series of ovals within ovals that represents the relationship between authorization classes. The smallest oval is Owner, encompassed by a larger oval labeled Group, encompassed by an oval labeled World, encompassed by an oval labeled Nobody.
For any NIS+ request, the system determines which class the requesting principal belongs to and the principal can then use whatever access rights belong to that class.
An object can grant any combination of access rights to each of these classes. Normally, however, a higher class is assigned the same rights as all the lower classes, as well as possible additional rights.
For instance, an object could grant read access to the nobody and world classes, both read and modify access to the group class, and read, modify, create, and destroy access to the owner class.
The four classes are described in detail, as follows.
The owner is a single NIS+ principal.
A principal making a request for access to an NIS+ object must be authenticated (present a valid DES credential) before being granted owner-access rights.
By default, an object's owner is the principal that created the object. However, an object's owner can cede ownership to another principal by two different methods:
Once a principal gives up ownership, that principal gives up all owner's access rights to the object and keeps only the rights the object assigns to either the group, the world, or nobody.
The object's group is a single NIS+ group. (In this context, group refers to NIS+ groups, and not operating system or net groups.)
A principal making a request for access to an NIS+ object must be authenticated (present a valid DES credential) and belong to the group before being granted group-access rights.
An NIS+ group is a collection of NIS+ principals, grouped together as a convenience for providing access to the namespace. The access rights granted to an NIS+ group apply to all the principals that are members of that group. (An object's owner, however, does not need to belong to the object's group.)
When an object is created, the creator can opt for a default group. A nondefault group can be specified either when the object is created or at any time later.
Information about NIS+ groups is stored in NIS+ group objects, under the groups_dir subdirectory of every NIS+ domain. (Note that information about NIS+ groups is not stored in the NIS+ group table. That table stores information about operating system groups.) Instructions for administering NIS+ groups are provided in Administering NIS+ Groups.
The world class contains all NIS+ principals that are authenticated by NIS+; that is, all members in the owner and group class, as well as all other principals who present a valid DES credential.
Access rights granted to the world class apply to all authenticated principals.
The nobody class contains all principals, even those without a valid DES credential.
NIS+ security applies authorization classes independently to a hierarchy of objects. Directory objects are the top level of the default hierarchy, then group or table objects, then columns, then entries. The following definitions provide more information about each level:
The four authorization classes apply at each level. Thus, a directory object has an owner and a group. Each table within a directory object has its own owner and group, which can be different from the owner and group of the directory object. Within a table, a column or an entry can have its own owner or group, which can be different from the owner and group of the table as a whole or of the directory object as a whole.
NIS+ objects specify access rights for NIS+ principals in the same way that operating system files specify permissions for operating system users. Access rights specify the types of operations that NIS+ principals are allowed to perform on NIS+ objects. (You can examine these by using the niscat -o command.)
NIS+ operations vary among different types of objects, but all operations fall into one of the four access-rights categories: read, modify, create, and destroy.
Every communication from an NIS+ client to an NIS+ server is a request to perform one of these operations on a specific NIS+ object. For instance, when an NIS+ principal requests the IP address of another workstation, it is effectively requesting read access to the hosts table object, which stores that type of information. When a principal asks the server to add a directory to the NIS+ namespace, it is actually requesting modify access to the directory's parent object.
These rights logically evolve down from directory to table to table column and entry levels. For example, to create a new table, you must have create rights for the NIS+ directory object where the table will be stored. When you create that table, you become its default owner. As owner, you can assign yourself create rights to the table which allows you to create new entries in the table. If you create new entries in a table, you become the default owner of those entries. As table owner, you can also grant table-level create rights to others. For example, you can give your table's group class table-level create rights. In that case, any member of the table's group can create new entries in the table. The individual member of the group who creates a new table entry becomes the default owner of that entry.