Overview of the Security Process

The security features of NIS+ protect the information in the namespace, as well as the structure of the namespace itself, from unauthorized access. Without these security features, any NIS+ client could obtain and change information stored in the namespace or even damage it.

NIS+ security is provided by two means: authentication and authorization. Authentication is the process by which an NIS+ server identifies the NIS+ principal who sent a particular request. Authorization is the process by which a server identifies the access rights granted to that principal.

About NIS+ Principals

An NIS+ principal is the entity that submits a request for NIS+ service from an NIS+ client (It can also be the entity that supplies the NIS+ service from an NIS+ server. Keep in mind that all NIS+ servers are also NIS+ clients, so much

of this discussion, though focused on clients, also applies to servers.) That entity may be someone who is logged into the client as a regular user, or someone who is logged on as superuser. In the first instance, the request actually comes from the client user; in the second instance, the request comes from the client workstation. Therefore, an NIS+ principal can be a client user or a client workstation.

NIS+ principals are identified by their credentials. When a user is logged into an NIS+ client as a regular user requests for NIS+ service include user credentials:

Figure 7-1

When a user is logged into an NIS+ client as superuser, request for services carries with it the client workstation's credentials. This distinction is important, since a client request could be denied because it is coming from the right NIS+ client but the wrong NIS+ principal.

NIS+ uses two types of credential: LOCAL and DES. (See"NIS+ Authentication" on page 95 for a description of these two types of credential.) These credentials are used to authenticate the NIS+ principal so that the server can determine whether the principal has been authorized to perform the requested operation.

About NIS+ Access Rights

NIS+ objects specify access rights for NIS+ principals in the same way that UNIX files specify permissions for UNIX users. Access rights specify the types of operations that NIS+ principals are allowed to perform on an NIS+ object.

NIS+ operations vary among different types of objects, but they fall into four classes: Read, Modify, Create, and Destroy. Every communication from an NIS+ client to an NIS+ server is, in effect, 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.

NIS+ objects specify their access rights as part of their object definitions. (You can examine these by using the niscat -o command, described on page 168.) So if the operation that a principal tries to perform on an object is authorized by the object's definition, the server performs it. If not, the request is denied.

An object does not grant access rights directly to a particular principal. Instead, it grants access rights to four classes of principal: Owner, Group, World, and Nobody. The principal who happens to be the object's owner gets the rights granted to the Owner class. The principals who belong to the object's Group class get the rights granted to the Group class. The World class encompasses all NIS+ principals that a server has been able to authenticate. Finally, the Nobody class is reserved for everyone, whether an authenticated principal or not. (Commands for working with access rights are described in Chapter 9, "Administering NIS+ Access Rights.") Figure 7-2 summarizes the entire process.

Figure 7-2

About Server Security Levels

NIS+ servers can operate at three security levels. These levels determine the types of credential a principal must submit for its request to be authenticated. They are described in Table 7-1 below:

Table 7-1

Security Level	Description
0	Security level 0 is designed for testing and setting up the initial NIS+ namespace. An NIS+ server running at security level 0 grants any NIS+ principal full access rights to all NIS+ objects in the domain. Requests that use invalid DES credentials are denied. No NIS+ credentials are created or maintained. Note that nis_passwd cannot function without credentials. Unless there are credentials existing from some previous higher level, nis_passwd cannot function in a level 0 environment. At level 0, other NIS+ commands that check or work with permissions, default down to using the UNIX file permission security system.
1	Security level 1 is designed only for testing and debugging; in particular, to debug without the complications of DES authentication. Do not use it on networks to which untrusted clients may have access. Security level 1 authenticates requests that use either LOCAL or DES credentials. Requests that don't use any credentials at all are assigned only the access rights granted to the Nobody class.
2	Security level 2, the default, is the highest level of security currently provided by NIS+. It only authenticates requests that use DES credentials. Requests that use LOCAL credentials or none at all are assigned the access rights granted to the Nobody class. Requests that use invalid DES credentials are denied.

A Note About Setting Up NIS+ Security

Security cannot be added to an existing namespace. You cannot set up security and the namespace independently. For this reason, instructions for setting up security are woven through the steps used to set up the other components of the namespace, in Part II of this manual.

NIS+ Authentication

Authentication is the mechanism used by an NIS+ server to verify the credentials of the NIS+ principal that has sent a request for NIS+ service. To explain the authentication mechanism, this section discusses:

• Types of credentials
• Where credentials are stored
• How credential information is created by the administrator
• How credentials are created by the client
• How credentials are examined by the server
• The cached public keys

Types of Credential

NIS+ principals can have two types of credential: LOCAL and DES. A client user can have both types, but a client workstation can only have a DES credential:

Table 7-2

Type of Credential	Client User	Client Workstation
LOCAL	Yes	No
DES	Yes	No

DES credential information can only be stored in the Cred table of the principal's home domain, regardless of whether that principal is a client user or a client workstation. LOCAL credentials, however can be stored in any domain. In fact, in order to log into a remote domain and be authenticated, a

client user must have LOCAL credentials in the Cred table of the remote domain. If the user does not have LOCAL credentials in the remote domain, they would have the access rights of the user nobody.

Figure 7-3

The LOCAL credentials are used to map the user ID of an NIS+ principal to its NIS+ principal name. Since the UID of the root user on every workstation is zero, a LOCAL credential doesn't make sense for a client workstation; thus, it is allowed only for a client user.

A DES credential is more complex than a LOCAL credential, not only because of the information it requires, but because of the process involved in creating and verifying it. To understand how DES authentication works, you need to distinguish between the credential itself and the information that is used to create and verify it. This book uses the term credential for the former and uses the term credential information for the latter. Thus, the credential is the bundle of numbers that is sent by the client to the server, and the credential information is the data that is stored in the Cred table, and used by the client to generate the credential and by the server to verify the credential.

The DES credential itself consists of a principal's secure RPC netname plus a verification field:

Figure 7-4

The secure RPC netname portion of the credential is the part used to actually identify the NIS+ principal. Every secure RPC netname begins with the prefix unix. If the principal is a client user, the second field in the netname is the user's UID. If the principal is a client workstation, the second field in the netname is the workstation's hostname. The last field is the principal's home domain:

Table 7-3

If the Principal Is:	The Domain Must Be:
A client user	The domain that contains the user's password entry and DES credentials.
A client workstation	The domain name returned by executing the domainname command on that workstation.

Remember that an NIS+ principal name always has a trailing dot, while a secure RPC netname never does.

The verification field of the credential is used to make sure the credential is not forged. It is generated from the credential information stored in the Cred table.

Where Credentials Are Stored

NIS+ credentials are stored in a Cred table. The Cred table is one of the 16 default NIS+ tables. Each domain has one Cred table, which stores the credentials of client workstations that belong to that domain and client users who are allowed to log onto them. The Cred tables are located in their domains' org_dir subdirectory:

Figure 7-5

You can view the contents of a Cred table with the niscat command, described in Chapter 12, "Administering NIS+ Tables."

The Cred table as shown in Table 7-4 has five columns:

Table 7-4

NIS+ Principal Name	Authentication Type	Authentication Name	Public Data	Private Data
NIS+ principal name of a client user	LOCAL	UID	GID list	none
NIS+ principal name of a client user or client workstation	DES	Secure RPC netname	Public key	Encrypted Private key

The second column, Authentication Type, determines the types of values found in the other four columns. If the authentication type is LOCAL, the other columns contain a client user's NIS+ principal name, UID, and GID; the last column is empty. If the authentication type is DES, the other columns contain

an NIS+ principal's name, secure RPC netname, public key, and encrypted private key. These keys are used in conjunction with other information to encrypt and decrypt a DES credential, as described later in this section.

Creating Credential Information

Credentials for NIS+ principals can be created any time after their domain has been set up; in other words, once a Cred table exists. When a namespace is first set up, credentials are created first for the administrators who will support the domain. Once they have credentials, they can create credentials for other administrators, client workstations, and client users. Step-by-step instructions for creating NIS+ credentials are distributed throughout this manual (see Table 7-5 below).

Table 7-5

Chapter	Task/Step	Page
Chapter 1	· "How to Set Up a Root Domain	page 3
	Step 10. Create DES credentials for the root master server.	page 14
	Step 16. Add your LOCAL credentials to the root domain.	page 19
	Step 17. Add your DES credentials to the root domain.	page 19
	Step 18. Add credentials for other administrators.	page 20
Chapter 2	· Setting Up NIS+ Clients	page 26
	Step 2. Create DES credentials for the new client workstation.	page 28
Chapter 4	· "Setting Up a Non-Root Domain	page 51
	Step 8. Add credentials for other administrators.	page 103
Chapter 8	· How to Create Credentials for an NIS+ Principal	page 127

You could add credentials to your namespace simply by following the instructions listed above. However, understanding the process by which credentials are used may help you uncover mistakes in the setup process or solve problems that may arise later.

The command used to create credentials is nisaddcred. (See "The nisaddcred Command" on page 125.) The nisaddcred command creates either LOCAL credentials or DES credentials.

---

Note - You can also use the nispopulate and nisclient scripts to create credentials. They, in turn, call the nisaddcred command

---

When used to create LOCAL credentials, nisaddcred simply extracts the client user's UID (and GID) from the client's login record and places it in the domain's Cred table.

When used to create DES credential information, nisaddcred goes through a two-part process: forming the principal's secure RPC netname and generating the principal's private and public keys. A secure RPC netname is formed by the principal's user ID from the password record and the domain name (e.g. unix.1050@sun.com).

To encrypt the private key, nisaddcred needs the principal's network password. So, when the nisaddcred command is invoked with the des argument, it prompts the principal for a network password. Normally, this password is the same as the principal's login password (if it is different, additional steps are required as described in "Network Password Different from Login Password" on page 103). The nisaddcred command generates a pair of random, but mathematically related 192-bit authentication keys using the Diffie-Hellman cryptography scheme. These keys are called the Diffie-Hellman key-pair, or simply "key-pair" for short.

One of these is the private key, the other is the public key. The public key is placed in the Public Data field of the Cred table. The private key is placed in the Private Data field, but only after being encrypted with the principal's network password:

Figure 7-6 nisaddcred

The principal's private key is encrypted as a security precaution because the Cred table, by default, is readable by all NIS+ principals, even unauthenticated ones.

How Credentials Are Created by the Client

When an NIS+ client sends a request to an NIS+ server it first sends along its DES credential if it is available. If the DES credential fails because either the client or the server does not have the proper keys, the client tries to send its LOCAL credential. If the LOCAL credential fails, the client attempts again, without credentials as Nobody.

To generate its DES credential, the client depends on the keylogin command, which must have been executed before the client tries to generate its credential. The keylogin command (often referred to simply as a "keylogin") is executed automatically by the client when an NIS+ principal logs on. (Note that keylogin is not performed automatically if the client's login password is different from the client's network password.) The purpose of the keylogin is to give the client access to its private key. The keylogin fetches the principal's

private key from the Cred table, decrypts it with the principal's network password (remember that the private key was originally encrypted with the principal's network password), and stores it locally for future NIS+ requests:

Figure 7-7 keylogin

To generate its DES credential, the client still needs the public key of the server to which it will send the request. This information is stored in the client's directory cache. Once the client has this information, it can form the verification field of the credential.

First, the client generates a random DES key (Kcs) for encrypting various credential information. Then the client uses its own private key and the server's public key to generate a common DES key that is used to encrypt the random DES key generated earlier. It then generates a time stamp that is encrypted with the DES key (Kcs) and combines it with other credential-related information into the verification field:

Figure 7-8 keylogi

To understand how a server examines these credentials, see "How Credentials are Examined by the Server" on page 106.

Network Password Different from Login Password

A principal's network password is usually the same as its login password, as mentioned earlier. They can, however, be different. If so, the private key cannot be decrypted by the client. When the principal logs on to the client, the client attempts an automatic keylogin, as usual. In other words, the client fetches the principal's private key from the Cred table, decrypting it with the principal's login password. However, when the credential information was first stored in the Cred table, the private key was encrypted with the principal's network password. As a result, the private key cannot be decrypted by the client and cannot be used for authentication:

Figure 7-9

To solve this problem, the NIS+ principal must give the NIS+ client a network password after the principal logs on. This requires an explicit keylogin. In general, a principal must keylogin any time its credentials changes. In this particular case, it should be after providing the nisaddcred command a network password that is different from the login password:

Figure 7-10

See "How to Keylogin" on page 139 for instructions.

How Credentials are Examined by the Server

To decrypt the DES credential, the server essentially reverses the encryption process performed by the client. First, the server uses the secure RPC netname portion of the credential to look up the principal's public key in the Cred table. Then, using its own private key (keep in mind that servers, because they are also clients, have credentials too) and the principal's public key, the server decrypts the DES key. Then it uses the DES key to decrypt the timestamp. If the timestamp is within a predetermined tolerance of the time the server received the message, the server authenticates the request.

This process satisfies the server. However, to let the client know that the information it receives indeed comes from a trusted server, the server encypts the timestamp with the DES key and sends it back to the client.

LOCAL credentials are not verified. Instead, the NIS+ server gets the NIS+ principal name of the principal who sent the request by looking up the principal's UID the third column of the Cred table.

Cached Public Keys

Occasionally, you may find that even though you have created the proper credentials and assigned the proper access rights, some client requests still get denied. The most common cause of this problem is the existence of stale objects with old versions of a server's public key. You can usually correct this problem by running nisupdkeys on the domain you are trying to access. (See Chapter 8 for information on using the nisupdkeys command.)

Because some keys are stored in files or caches, nisupdkeys cannot always correct the problem. At times you might need to update the keys manually. To do that, you'll need to understand how a server's public key, once created, is propagated through namespace objects. The process generally has five stages of propagation:

• Stage 1--Server's public keys are generated
• Stage 2--Public keys are propagated to directory objects
• Stage 3--Directory objects are propagated into client files
• Stage 4--When a replica is addes to the domain
• Stage 5--When the server's public keys are changed

Each stage is described below.

Stage 1 -- Server's Public Key Is Generated

An NIS+ server is first an NIS+ client. So, its public key is generated in the same way as any other NIS+ client's public key: with the nisaddcred command. The public key is then stored in the Cred table of the server's home domain, not of the domain the server will eventually support.

Stage 2 -- Public Key Is Propagated to Directory Objects

Once you have set up an NIS+ domain and an NIS+ server, you can associate the server with a domain. This association is performed by the nismkdir command. When the nismkdir command associates the server with the directory, it also copies the server's public key from the Cred table to the domain's directory object. For example, assume the server is a client of the Wiz.Com. root domain, and is made the master server of the Sales.Wiz.Com. domain:

Figure 7-11

Its public key is copied from the cred.org_dir.Wiz.Com. domain and placed in the Sales.Wiz.Com. directory object. This can be verified with the niscat -o Sales.wiz.com. command.

Stage 3 -- Directory Objects Are Propagated into Client Files

All NIS+ clients are initialized with the nisinit utility or as described in Chapter 2, "Setting Up NIS+ Clients." (Clients can also be initialized with the nisclient script.) Among other things, this utility creates a coldstart file /var/nis/NIS_COLDSTART. The coldstart file is used to initialize the client's directory cache /var/nis/NIS_SHARED_DIRCACHE. The coldstart file contains a copy of the directory object of the client's domain. Since the directory object already contains a copy of the server's public key, the key is now propagated into the coldstart file of the client.

In addition when a client makes a request to a server outside its home domain, a copy of the remote domains directory object is stored in the client's NIS_SHARED_DIRCACHE file. You can examine the contents of the client's cache by using the nisshowcache command, described on page 180.

This is the extent of the propagation until a replica is added to the domain or the server's key changes.

Stage 4 -- When a Replica is Added to the Domain

When a replica server is added to a domain, the nisping command (described on page 181) is used to download the NIS+ tables, including the Cred table, to the new replica. Therefore, the original server's public key is now also stored in the replica server's Cred table.

Stage 5 -- When the Server's Public Key Is Changed

If you decide to change DES credentials for the server (that is, for the root identity on the server), its public key will change. As a result, the public key stored for that server in the Cred table will be different from those stored in:

• The Cred table of replica servers (for a few minutes only)
• The main directory object of the domain supported by the server (until its time-to-live expires)

• The NIS_COLDSTART and NIS_SHARED_DIRCACHE files of every client of the domain supported by server (until their time-to-live expires, usually 12 hours)
• The NIS_SHARED_DIRCACHE file of clients who have made requests to the domain supported by the server (until their time-to-live expires)

As indicated above, most of these locations will be updated automatically within a time ranging from a few minutes to 12 hours, To update the server's keys in these locations immediately, use the following commands:

Table 7-6

Location	Command	See
Cred table of replica servers (instead of using nisping, you can wait a few minutes until the table is updated automatically)	nisping	page 181
Directory object of domain supported by server	nisupdkeys	page 136
NIS_COLDSTART file of clients	nisinit -c	page 178
NIS_SHARED_CACHE file of clients	nis_cachemg	page 179

---

Note - You must first kill the existing nis_cachemgr before restarting nis_cachemgr.

---

NIS+ Authorization in Depth

Access rights specify the type of operation that NIS+ principals, both authenticated and unauthenticated, can perform on an NIS+ object. NIS+ offers four types of access rights as listed in Table 7-7.

Table 7-7

Access Right	Description
Read	Principal can read the contents of the object.
Modify	Principal can modify the contents of the object.
Destroy	Principal can destroy objects in a table or directory.
Create	Principal can create new objects in a table or directory.

These rights are granted by each object to four different classes of NIS+ principals, not to a particular NIS+ principal. These are called authorization classes.

Authorization Classes

To assign access rights, every NIS+ object uses four authorization classes: Owner, Group, World, and Nobody. An object can grant any combination of access rights to each of these classes. For instance, an object could grant Read access to the World class, but Modify access only to the Group and Owner. Thus, any NIS+ principal that belonged to the World class could read the object, but only the NIS+ principals that belong to the Group and Owner class could modify the object. Each class is described below.

The Object's Owner

The Owner is a single NIS+ principal. By default, an object's owner is the principal that created the object. However, an object's owner can cede ownership to another principal in two ways. One way is for the principal to specify a different owner at the time it creates the object (see "Overriding Defaults" on page 147). Another way is for the principal to change the ownership of the object after the object is created (see "The nischown Command" on page 154).

Once a principal gives up ownership, it 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

The object's group is a single NIS+ group. 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. By default, when an object is created, it is assigned the NIS+ principal's default group. (An object's Owner, however, does not need to belong to the object's Group.)

Information about NIS+ groups is not stored in the NIS+ Group table. That table stores information about UNIX groups. Information about NIS+ groups is stored in NIS+ group objects, under the groups_dir subdirectory of every NIS+ domain:

Figure 7-12

Instructions for administering NIS+ groups are provided in Chapter 10, "Administering NIS+ Groups".

The World

The World is the class of all NIS+ principals that are authenticated by NIS+. Access rights granted to the World apply to all authenticated principals.

Nobody

Nobody is a class reserved for unauthenticated requests. Note that requests that are not authenticated because they sent along invalid credentials are simply denied, and not given any access rights, not even those of the Nobody class.

Where Access Rights are Stored

An object's access rights are specified in its definition. (Note that this information is part of the object's definition; it is not an NIS+ table.) The access rights can be viewed by using niscat -o object_name.

Table 7-8

Object's Owner	Object's Group Owner	Access Rights: Owner	Access Rights: Group	Access Rights: World	Access Rights: Nobody
The NIS+ principal that created the object or that was assigned ownership by the nischown command.	The NIS+ group owner of the object.	The access rights granted to the object owner	The access rights granted to the principals in the object's group.	The access rights granted to any authenticated NIS+ principal.	The access rights granted to everyone, whether authenticated or not.

Access rights are displayed as a list of 16 characters, like this:

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

Each character represents a type of access right. Thus, r represents Read, m represents Modify, d represents Destroy, c represents Create, and - 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 7-13

---

Note - Unlike UNIX file systems, the first set of rights is for Nobody, not for the Owner.

---

How Access Rights Are Assigned

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. The default group is the group named in the NIS_GROUP environment variable. The default set of access rights is:

Table 7-9

Nobody	Owner	Group	World
-	Read	Read	Read
-	Modify	-	-
-	Create	-	-
-	Destroy	-	-

NIS+ provides several different ways to change these default rights. The first is the NIS_DEFAULTS environment variable. That variable stores a set of security related default values, one of which is access rights. The defaults stored in the NIS_DEFAULTS variable are assigned to every object that is created while they are in effect. If the value of this variable is changed on a particular client, any object created from that client will be assigned the new values. However, previously created objects will not be affected. Instructions for changing the NIS_DEFAULTS variable are provided in the section titled "Changing Defaults" on page 146.

A second way to affect access rights is with the -D option, which is available with several NIS+ commands. The -D option specifies the default values that will be applied to all the objects acted upon by the command. In other words, it overrides the default values stored by the NIS_DEFAULTS variable, but only for the object affected by that particular instance of the command. For instructions, see "Overriding Defaults" on page 147.

The third way is to explicitly change an object's access rights (or other security defaults) using one of the NIS+ commands designed for that purpose, such as nischmod. Instructions are provided in Chapter 9, "Administering NIS+ Access Rights."

NIS+ tables provide additional levels of security not provided by other types of NIS+ objects. Information in an NIS+ table can be accessed by column or entry:

Figure 7-14

Besides the rights that can be assigned to the table as a whole, NIS+ allows you to assign access rights to the columns and entries of a table. Those rights can provide additional access, but they cannot restrict the access provided by the table as a whole. For instance, if the table provided Read rights to the World class, a column could give the World class Modify rights, but it could not restrict Read access to only the Owner or the Group.

---

Note - Any Read rights assigned to the Owner or Group in the Read column would be overridden by the World Read rights granted by the table object.

---

A column or entry 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 a couple of examples.

Assume a table object granted Read rights to the table's Owner:

                     Nobody  Owner   Group   World
Table Access Rights  :  ----    r---    ----    ----

This would mean that only the table's owner could read the contents of the entire table. A principal who is not the owner would have no access. However, a particular entry in the table could also grant Read rights to the Group class:

                       Nobody  Owner   Group   World
  Table Access Rights  :  ----    r---    ----    ----
  Entry1 Access Rights :  ----    ----    r---    ----

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:

                      Nobody  Owner   Group   World
Table Access Rights   :  ----    r---    ----    ----
Entry1 Access Rights  :  ----    ----    r---    ----
Column1 Access Rights :  ----    ----    ----    r---

Members of the World class could now read that column for all entries in the table. Here is a representation of what would be displayed to members of the World class who tried to read the table:

Figure 7-15

Here is another example. Assume a table assigned Read rights to the Group:

                        Nobody  Owner   Group   World
  Table Access Rights   :  ----    ----    r---   ----

Any member of the group could read the contents of the entire table, but could not create, modify, or destroy them. However, a particular entry could assign the group Modify rights:

                      Nobody  Owner   Group   World
Table Access Rights   :  ----    ----    r---   ----
Entry1 Access Rights  :  ----    ----    -m--   ----

Members of the entry's group could now modify the contents of the entry. However, they could still not destroy the entry. However, if a particular column assigned Create and Destroy rights to the Group . . .

                      Nobody  Owner   Group    World
Table Access Rights   :  ----    ----    r---    ----
Entry1 Access Rights  :  ----    ----    -m--    ----
Col1 Access Rights    :  ----    ----    --cd    ----

. . . every member of an entry's group could create or destroy information about the entry as long as it was contained in that column.

How a Server Grants Access Rights to Tables

The process for granting access rights at the object level has been already described (see "Overview of the Security Process" on page 91). However, because of the overlapping rights of table objects, columns, and entries, this section discusses how a server grants access to tables objects, entries, and columns during each type of operation: read, modify, destroy, and create.

Note that at security level 0, a server enforces no access rights and all clients are granted full access rights to the table object.

As described earlier, after authenticating a request, an NIS+ server determines the type of operation and the object of the request. If that object is a directory or group, the server simply examines the object's definition and grants the request, provided the object has assigned the proper rights to the principal. However, if the object is a table, the server follows a more involved process. The process varies somewhat depending on the operation, but it follows this general rule of thumb:

First, check rights at the table level

Then at the entry level

Then at the column level.

Following are detailed examples of the process involved in each type of operation. While going through them, keep in mind the four factors that a server must consider when deciding whether to grant access

1. The type of operation requested by the principal

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

3. The authorization class the principal belongs to for that particular object

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

Granting Access to Read or Modify a Table

When a principal requests to read or modify the contents of a table (for example, by issuing the niscat or nistbladm command), an NIS+ server employs the following logic to grant access to the principal. For this example, assume that the principal is a member of the group named in the table's group authorization class, and is trying to read or modify the entire table.

The server first checks the table object's rights. If the table grants Read access to the group, the principal is allowed to read all the contents of the table, and the server does not proceed to check rights of columns or entries. (The shaded boxes represent the columns and entries that the principal is allowed to read.)

Figure 7-16

If the table object does not grant Read access to the group, the server checks the access rights granted by the table entries the principal is trying to access.

If any of those entries grants its group Read rights, and if the principal belongs to that group (which may be different from the table's group), the server allows the principal to read that entry's contents. Then it checks the rights granted by the next entry. (The shaded rows below represent the entries that have given the group Read rights.)

Figure 7-17

The server proceeds to check column rights only if none of the entries the principal has tried to access has granted the group Read rights.

If a server finds that no columns in the table have granted their group Read rights, it returns an error message, stating that the principal does not have permission to access the object. However, if any column grants its group Read rights, and if the principal belongs to that group (which may also be different from the table or even the entries' group), the server displays the entries that specify the same group, but censors the columns that do not grant their group Read rights. Censored columns display the string *NP* (for "no permission"). If all entries specified the same group, this would be displayed:

Figure 7-18

However, if only some entries (e.g., 1, 3, 4, and 7) specified the same group, this would be displayed:

Figure 7-19

Granting Access to Destroy Table Entries

When a principal requests to delete a table, the server checks the access rights granted to the principal by the directory that contains the table. However, when a principal requests to delete a table entry, the server checks its various

Destroy rights. Assume that the principal is a member of the group named in the table's group authorization class, and that the principal is trying to delete entries 1 and 5.

If the table object grants its group Destroy rights, the principal is allowed to remove any entry from the table (columns cannot be removed). The server checks no further. If the table object does not grant the group Destroy rights, the server checks access rights at the entry level.

At the entry level, the server only checks the rights of the entries that the principal is trying to destroy (that is, 1 and 5). If one of those entries grants its group Destroy rights, and if the principal belongs to that group, the principal is allowed to delete that entry. If one of those entries does not grant the group Destroy rights, or if the principal does not belong to the entry's group authorization class, the principal is not allowed to delete the entry.

If no entries grant their group Destroy rights, an error message is returned, stating that the principal does not have permission to access the object.

Since no columns can be deleted from a table, the server does not check column access rights during a Destroy operation.

Granting Access to Create Table Entries

When a principal tries to create a table, the server checks the access rights granted to the principal by the directory under which the table will be created. However, when a principal tries to add new table entries to an existing table, the server checks various Create and Modify rights. For this example, assume that the principal is a member of the group named in the table's group authorization class, and that the principal is trying to add entries 8 and 9.

If the table object grants its group Create rights, the principal is allowed to add entries to the table (columns cannot be added). The server checks no further. However, if the object does not grant its group Create rights, the server checks whether the entry that the principal is trying to create already exists.

If the entry exists, the server checks whether the table object has granted its group Modify rights. If it has, the server replaces the existing entry with the new one and checks no further. If the table has not granted its group Modify rights, the server checks rights at the entry level.

At the entry level, the server checks not whether the entry has granted the group Create rights, but whether it has granted the group Modify rights. If the entry has granted Modify rights to its group, and if the principal is a member of that group (which may not be the same as the table object's group), the server replaces the existing entry with the new one and no further checking is done.

If the entry has not granted Modify rights to its group, or if the principal is not a member of that group, an error message is returned, stating that the principal does not have permission to modify the object.

Since no columns can be added to a table, the server does not check column access rights during a Create operation.