Chapter 15

Administering NIS+ Access Rights

This chapter describes NIS+ access rights and how to administer them.

Note - Some NIS+ security tasks can be performed more easily with Solstice AdminSuite tools if you have them available.

Note - NIS+ might not be supported in a future release. Tools to aid the migration from NIS+ to LDAP are available in the Solaris 9 operating environment (see Part V). For more information, visit http://www.sun.com/directory/nisplus/transition.html.

NIS+ Access Rights

NIS+ access rights determine what operations NIS+ users can perform and what information they have access to. This chapter assumes that you have an adequate understanding of the NIS+ security system in general, and in particular of the role that access rights play in that system (see Chapter 11, NIS+ Security Overview for this information).

For a complete description of NIS+ access-related commands and their syntax and options, see the NIS+ man pages.

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.


	Chapter 15 Administering NIS+ Access Rights This chapter describes NIS+ access rights and how to administer them. Note - Some NIS+ security tasks can be performed more easily with Solstice AdminSuite tools if you have them available. Note - NIS+ might not be supported in a future release. Tools to aid the migration from NIS+ to LDAP are available in the Solaris 9 operating environment (see Part V). For more information, visit `http://www.sun.com/directory/nisplus/transition.html`. NIS+ Access Rights NIS+ access rights determine what operations NIS+ users can perform and what information they have access to. This chapter assumes that you have an adequate understanding of the NIS+ security system in general, and in particular of the role that access rights play in that system (see Chapter 11, NIS+ Security Overview for this information). For a complete description of NIS+ access-related commands and their syntax and options, see the NIS+ man pages. 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.