Introduction to Authorization and Access Rights

See NIS+ Authorization and Access—Introduction for a description of how authorization and access rights work with NIS+ credentials and authentication to provide security for the NIS+ namespace.

Authorization Classes—Review

As described more fully in Authorization Classes, NIS+ access rights are assigned on a class basis. There are four different NIS+ classes:

• Owner. The owner class is a single NIS+ principal. By default, an object's owner is the principal that created the object. However, an object's owner can transfer ownership to another principal who then becomes the new owner.

• Group. The group class is a collection of one or more NIS+ principals. An NIS+ object can have only one NIS+ group.

• World. The world class contains all NIS+ principals that are authenticated by NIS+ (in other words, everyone in the owner and group class, plus everyone else who presents a valid DES credential).

• Nobody. The nobody class is composed of anyone who is not properly authenticated (in other words, anyone who does not present a valid DES credential).

Access Rights—Review

As described more fully in NIS+ Access Rights, there are four types of NIS+ access rights:

• Read. A principal with read rights to an object can view the contents of that object.

• Modify. A principal with modify rights to an object can change the contents of that object.

• Destroy. A principal with Destroy rights to an object can delete the object.

• Create. A principal with create rights to a higher level object can create new objects within that level. In other words, if you have create rights to an NIS+ directory object, you can create new tables within that directory. If you have create rights to an NIS+ table, you can create new columns and entries within that table.

Keep in mind that 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.

Concatenation of Access Rights

Authorization classes are concatenated. In other words, the higher class usually belongs to the lower class and automatically gets the rights assigned to the lower class. It works like this:

• Owner class. An object's owner may, or may not, belong to the object's group. If the owner does belong to the group, then the owner gets whatever rights are assigned to the group. The object's owner automatically belongs to the world and nobody classes, so the owner automatically gets whatever rights that object assigns to those two classes.

• Group class. Members of the object's group automatically belong to the world and nobody classes, so the group members automatically get whatever rights that object assigns to world and nobody.

• World class. The world class automatically gets the same rights to an object that are given to the nobody class.

• Nobody class. The nobody class only gets those rights an object specifically assigns to the nobody class.

The basic principle that governs this is that access rights override the absence of access rights. In other words, a higher class can have more rights than a lower class, but not fewer rights. (The one exception to this rule is that if the owner is not a member of the group, it is possible to give rights to the group class that the owner does not have.)

How Access Rights Are Assigned and Changed

When you create an NIS+ object, NIS+ assigns that object a default set of access rights for the owner and group classes. By default, the owner is the NIS+ principal who creates the object. The default group is the group named in the NIS_GROUP environment variable.

Specifying Different Default Rights

NIS+ provides two different ways to change the default rights that are automatically assigned to an NIS+ object when it is created.

• The NIS_DEFAULTS environment variable. NIS_DEFAULTS stores a set of security-related default values, one of which is access rights. These default access rights are the ones automatically assigned to an object when it is created. (See Displaying NIS+ Defaults—The nisdefaults Command for details.)

  If the value of the NIS_DEFAULTS environment variable is changed, objects created after the change are assigned the new values. However, previously created objects are not affected.

• The -D option, which is available with several NIS+ commands. When you use the -D option as part of the command to create an NIS+ object, it overrides the default rights specified by the NIS_DEFAULTS environment variable and allows you to explicitly specify an initial set of rights for that object. (See Specifying Nondefault Security Values at Creation Time for details.)

Changing Access Rights to an Existing Object

When an NIS+ object is created, it comes into existence with a default set of access rights (from either the NIS_DEFAULTS environment variable or as specified with the -D option). These default rights can be changed with the

• nischmod command

• nistbladm command for table columns

Table, Column, and Entry Security

NIS+ tables allow you to specify access rights on the table three ways:

• You can specify access rights to the table as a whole.

• You can specify access rights to each entry (row) by itself.

• You can specify access rights to each table column individually.

A field is the intersection between a column and an entry (row). All data values are entered in fields.

These column- and entry level access rights allow you to specify additional access to individual rows and columns that override table level restrictions, but column and entry level rights cannot be more restrictive than the table as a whole:

• Table. The table level is the base level. Access rights assigned at the table level apply to every piece of data in the table unless specifically modified by a column or entry exception. Thus, the table level rights should be the most restrictive.

  ---

  Note –

  Remember that authorization classes concatenate. A higher class gets the rights assigned to lower classes. See Concatenation of Access Rights.

  ---

• Column. Column-level rights allow you to grant additional access rights on a column-by-column basis. For example, suppose the table level granted no access rights whatsoever to the world and nobody classes. In such a case, no one in those two classes could read, modify, create, or destroy any data in the table. You could use column-level rights to override that table level restriction and permit members of the world class the right to view data in a particular column.

  On the other hand, if the table level grants table-wide read rights to the owner and group classes, you cannot use column-level rights to prevent the group class from having read rights to that column.

• Entry (row). entry level rights allow you to grant additional access rights on a row-by-row basis. For example, this allows you to permit individual users to change entries that apply to them, but not entries that apply to anyone else.

  Keep in mind that an entry's group does not have to be the same as the table's group. Tables and entries can have different groups. This means that you can permit members of a particular group to work with one set of entries while preventing them from affecting entries belonging to other groups.

Table, Column, Entry Example

Column- or entry level access rights can provide additional access in two ways: by extending the rights to additional principals or by providing additional rights to the same principals. Of course, both ways can be combined. Following are some examples.

Assume a table object granted read rights to the table's owner:

This means that the table's owner could read the contents of the entire table but no one else could read anything. You could then specify that Entry-2 of the table grant read rights to the group class:

Although only the owner could read all the contents of the table, any member of the table's group could read the contents of that particular entry. Now, assume that a particular column granted read rights to the world class:

Members of the world class could now read that column for all entries in the table . Members of the group class could read everything in Column-1 (because members of the group class are also members of the world class) and also all columns of Entry-2. Neither the world nor the group classes could read any cells marked *NP* (for Nor Permitted).

Rights at Different Levels

This section describes how the four different access rights (read, create, modify, and destroy) work at the four different access levels (directory, table, column, and entry).

The objects that these various rights and levels act on are summarized in Table 15–5:

Read Rights

• Directory. If you have read rights to a directory, you can list the contents of the directory.

• Table. If you have read rights to a table, you can view all the data in that table.

• Column. If you have read rights to a column, you can view all the data in that column.

• Entry. If you have read rights to an entry, you can view all the data in that entry.

Create Rights

• Directory. If you have create rights at the directory level, you can create new objects in the directory such as new tables.

• Table. If you have create rights at the table level, you can create new entries. (You cannot add new columns to an existing table regardless of what rights you have.)

• Column. If you have create rights to a column, you can enter new data values in the fields of that column. You cannot create new columns.

• Entry. If you have create rights to an entry, you can enter new data values in the fields of that row. (Entry level create rights do not permit you to create new rows.)

Modify Rights

• Directory. If you have modify rights at the directory level, you can move or rename directory objects.

• Table. If you have modify rights at the table level, you can change any data values in the table. You can create (add) new rows, but you cannot create new columns. If an existing field is blank, you can enter new data in it.

• Column. If you have modify rights to a column, you can change the data values in the fields of that column.

• Entry. If you have modify rights to an entry, you can change the data values in the fields of that row.

Destroy Rights

• Directory. If you have destroy rights at the directory level, you can destroy existing objects in the directory such as tables.

• Table. If you have destroy rights at the table level, you can destroy existing entries (rows) in the table but not columns. You cannot destroy existing columns in a table: you can only destroy entries.

• Column. If you have destroy rights to a column, you can destroy existing data values in the fields of that column.

• Entry. If you have destroy rights to an entry, you can destroy existing data values in the fields of that row.

Where Access Rights Are Stored

An object's access rights are specified and stored as part of the object's definition. This information is not stored in an NIS+ table.

Viewing an NIS+ Object's Access Rights

The access rights can be viewed by using the niscat command:

niscat -o objectname

Where objectname is the name of the object whose access rights you want to view.

This command returns the following information about an NIS+ object:

• Owner. The single NIS+ principal who has ownership rights. This is usually the person who created the object, but it could be someone to whom the original owner transferred ownership rights.

• Group. The object's NIS+ group.

• Nobody class access rights. The access rights granted to everyone, whether they are authenticated (have a valid DES credential) or not.

• Owner class access rights. The access rights granted to the object's owner.

• Group class access rights. The access rights granted to the principals in the object's group.

• World class access rights. The access rights granted to all authenticated NIS+ principals.

Access rights for the four authorization classes are displayed as a list of 16 characters, like this:

	r---rmcdr---r---

Each character represents a type of access right:

• r represents read rights.

• m represents modify rights.

• d represents destroy rights.

• c represents create rights.

• - represents no access rights.

The first four characters represent the access rights granted to nobody, the next four to the owner, the next four to the group, and the last four to the world:

Figure 15–1 Access Rights Display

Unlike UNIX file systems, the first set of rights is for nobody, not for the owner.

Default Access Rights

When you create an object, NIS+ assigns the object a default owner and group, and a default set of access rights for all four classes. The default owner is the NIS+ principal who creates the object. The default group is the group named in the NIS_GROUP environment variable. Table 15–6, shows the default access rights.

If you have the NIS_DEFAULTS environment variable set, the values specified in NIS_DEFAULTS will determine the defaults that are applied to new objects. When you create an object from the command line, you can use the -D flag to specify values other than the default values.

How a Server Grants Access Rights to Tables

This section discusses how a server grants access to tables objects, entries, and columns during each type of operation: read, modify, destroy, and create.

At security level 0, a server enforces no NIS+ access rights and all clients are granted full access rights to the table object. Security level 0 is only for administrator setup and testing purposes. Do not use level 0 in any environment where ordinary users are performing their normal work.

The four factors that a server must consider when deciding whether to grant access are:

• The type of operation requested by the principal

• The table, entry, or column the principal is trying to access

• The authorization class the principal belongs to for that particular object

• The access rights that the table, entry, or column has assigned to the principal's authorization class

After authenticating the principal making the request by making sure the principal has a valid DES credential, an NIS+ server determines the type of operation and the object of the request.

• Directory. If the object is a directory or group, the server examines the object's definition to see what rights are granted to the four authorization classes, determines which class the principal belongs to, and then grants or denies the request based on the principal's class and the rights assigned to that class.

• Table. If the object is a table, the server examines the table's definition to see what table level rights are granted to the four authorization classes, and determines which class the principal belongs to. If the class to which the principal belongs does not have table level rights to perform the requested operation, the server then determines which row or column the operation concerns and determines if there are corresponding row- or column-level access rights permitting the principal to perform the requested operation.