Access Rights

Access rights are granted not to specific NIS+ principals, but to four categories of NIS+ principals: Nobody, Owner, Group, and World, as previously described. The four types of NIS+ access rights are Read, Modify, Create, and Destroy, as shown in Table 5-6.

Each object grants access rights to the four categories of NIS+ principals: Nobody, Owner, Group, and World. Access rights for each object consist of a string of 16 characters, 4 for each principal category. In the example shown in Figure 5-8, all access rights are permitted for each authentication category.

Figure 5-8  NIS+ authentication categories and access rights.

In the following example, Nobody has read permission (r---); Owner has read, modify, create, and destroy permissions (rmcd); Group has read and modify permissions(rm--), and World has read permission (r---).

r---rmcdrm--r---

An NIS+ table or directory can grant one or more access rights to one or more categories of clients. For example, a directory could grant Read access to the World category but only Modify access to the Group and Owner. NIS+ authorization supports flexible and secure administration. For example, the Group access right allows finer control for NIS+ administration. It can be used to maintain security and control as administrative authority becomes more decentralized. When NIS+ domains are first created, a group consisting of central administrative personnel could have only Modify and Create access rights to directories across the network. As the domain evolves and decentralizes, directories could grant these access rights to new groups that contain both local and central administrative personnel. Expanding access rights while maintaining access to existing administrators permits the smooth transition of control.

When you create an object, NIS+ assigns the object a default owner, group, and set of access rights. The default owner is the NIS+ principal who creates the object (in this case, you). The default group is the group named in the NIS_GROUP environment variable. The default set of access rights is:

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

You can change these default values in several different ways. One way to change the access rights of an NIS+ object or table entry is to use the nischmod command. To use the nischmod command, you must already have Modify rights to the object or entry. The nischmod command syntax is much like the syntax for the chmod command. You add access rights using the + operator and remove access rights using the - operator. For example, you would use the following syntax to add Read and Modify rights to the Group of the esg.eng.starlight.com. directory:

oak% nischmod g+rm esg.eng.starlight.com.

See the manual page for nischmod(1) for more information. See the section “NIS+ Commands” on page 115 for a list of the NIS+ commands.

Once they are set, the access rights for a table object define the level of security for that table object. The only way to make entries or columns in a table more secure is to change the access rights for the table object itself. You can, however, provide additional access to the information stored in a table object by extending the rights to additional principals or by providing additional access rights to existing principals.

For example, your company may have a policy that permits anybody in the company to create, modify, or delete entries for a particular email alias. Access to all other aliases is restricted to the owner of the aliases table. To implement this policy, you would create the most restrictive rights for the aliases table object itself (----rmcdr---r---) and grant free access to the entry that contains the particular alias (rmcdrmcdrmcdrmcd).

You can use the nistbladm command to set access rights to a table when it is created, to set access rights to an entry and a column when you create the entry, or to modify the access rights of an existing table. See the nistbladm(1) manual page for more information.

The NIS+ Updating Model

The NIS+ updating model is more reliable and efficient than the NIS updating model. NIS+ stores a primary copy of a directory on a master server. Zero or more replica servers store replicas of the primary copy. When you use AdminSuite or the NIS+ commands to administer NIS+, changes are made only to the directory on the master server. When a master server receives an update to an object--whether a directory, group, link, or table--the server waits about two minutes for other updates so that it can batch the updates. When the waiting period is complete, the server stores the updates on disk and in a transaction log, along with a timestamp, and propagates the changes to its replica servers. In contrast to NIS updates, which usually take a day or more to propagate in large organizations, NIS+ incremental updates are automatically and quickly propagated to the replicas.

The NIS+ updating model allows for more efficient use of network bandwidth because only the changes are transmitted from the master to the replica servers. In addition, replica servers are contacted only once, with an aggregate update to all tables occurring within a short time. If replicas are out-of-date, they ask for updated information.

The NIS+ transaction log model provides rollback recovery and consistency of NIS+ databases, even when a server fails during an update. NIS+ master and replica servers can use the transaction log to automatically repair databases to their state before the failure occurred.