Chapter 15 Administering NIS+ Access Rights

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

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

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 System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP)). 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.

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.

Specifying Access Rights in Commands

This section assume an NIS+ environment running at security level 2 (the default level).

This section describes how to specify access rights, as well as owner, group owner, and object, when using any of the commands described in this chapter.

Syntax for Access Rights

This subsection describes the access rights syntax used with the various NIS+ commands that deal with authorization and access rights.

Class, Operator, and Rights Syntax

Access rights, whether specified in an environment variable or a command, are identified with three types of arguments: class, operator, and right.

• Class. Class refers to the type of NIS+ principal (authorization class) to which the rights will apply.

• Operator. The operator indicates the kind of operation that will be performed with the rights.

• Rights. The rights are the access rights themselves. The accepted values for each are listed below.

You can combine operations on a single command line by separating each operation from the next with a comma (,).

Syntax for Owner and Group

• Owner. To specify an owner, use an NIS+ principal name.

• Group. To specify an NIS+ group, use an NIS+ group name with the domain name appended.

  Remember that principal names are fully qualified (principalname.domainname).

  For owner

principalname

For group

groupname.domainname

Syntax for Objects and Table Entries

Objects and table entries use different syntaxes.

• Objects use simple object names.

• Table entries use indexed names.

For objects

objectname

For table entries

columnname=value],tablename

In this case, the brackets are part of the syntax.

Indexed names can specify more than one column-value pair. If so, the operation applies only to the entries that match all the column-value pairs. The more column-value pairs you provide, the more stringent the search.

For example:

Columns use a special version of indexed names. Because you can only work on columns with the nistbladm command, seeThe nistbladm Command for more information.

Displaying NIS+ Defaults—The nisdefaults Command

The nisdefaults command displays the seven default values currently active in the namespace. These default values are either

• Preset values supplied by the NIS+ software

• The defaults specified in the NIS_DEFAULTS environment variable (if you have NIS_DEFAULTS values set)

Any object that you create on this machine will automatically acquire these default values unless you override them with the -D option of the command you are using to create the object.

You can use these options to display all default values or any subset of them:

• To display all values in verbose format, type the nisdefaults command without arguments.

master% nisdefaults
Principal Name : topadmin.doc.com.
Domain Name : doc.com.
Host Name : rootmaster.doc.com.
Group Name : salesboss
Access Rights : ----rmcdr---r---
Time to live : 12:00:00:00:00
Search Path : doc.com.

• To display all values in terse format, add the -a option.

• To display a subset of the values, use the appropriate options. The values are displayed in terse mode. For example, to display the rights and search path defaults in terse mode, type:

  rootmaster% nisdefaults -rs ----rmcdr---r--- doc.com.

• To display a subset of the values in verbose mode, add the -v flag.

Setting Default Security Values

This section describes how to perform tasks related to the nisdefaults command, the NIS_DEFAULTS environment variable, and the -D option. The NIS_DEFAULTS environment variable specifies the following default values:

• Owner

• Group

• Access rights

• Time-to-live.

The values that you set in the NIS_DEFAULTS environment variable are the default values applied to all NIS+ objects that you create using that shell (unless overridden by using the -D option with the command that creates the object).

You can specify the default values (owner, group, access rights, and time-to-live) specified with the NIS_DEFAULTS environment variable. Once you set the value of NIS_DEFAULTS, every object you create from that shell will acquire those defaults, unless you override them by using the -D option when you invoke a command.

Displaying the Value of NIS_DEFAULTS

You can check the setting of an environment variable by using the echo command, as shown below:

client% echo $NIS_DEFAULTS
owner=butler:group=gamblers:access=o+rmcd

You can also display a general list of the NIS+ defaults active in the namespace by using the nisdefaults command as described in Displaying NIS+ Defaults—The nisdefaults Command.

Changing Defaults

You can change the default access rights, owner, and group, by changing the value of the NIS_DEFAULTS environment variable. Use the environment command that is appropriate for your shell (setenv for C-shell or $NIS_DEFAULTS=, export for Bourne and Korn shells) with the following arguments:

• access=right, where right are the access rights using the formats described in Specifying Access Rights in Commands.

• owner=name, where name is the user name of the owner.

• group=group, where group is the name of the default group

You can combine two or more arguments into one line separated by colons:

-owner=principal-name:-group=group-name

Table 15–13 shows some examples:

All objects and entries created from the shell in which you changed the defaults will have the new values you specified. You cannot specify default settings for a table column or entry; the columns and entries simply inherit the defaults of the table.

Resetting the Value of NIS_DEFAULTS

You can reset the NIS_DEFAULTS variable to its original values, by typing the name of the variable without arguments, using the format appropriate to your shell:

For C shell

client# unsetenv NIS_DEFAULTS

For Bourne or Korn shell

client$ NIS_DEFAULTS=; export NIS_DEFAULTS

Specifying Nondefault Security Values at Creation Time

You can specify different (that is, nondefault) access rights, owner, and group, any time that you create an NIS+ object or table entry with any of the following NIS+ commands:

• nismkdir—Creates NIS+ directory objects

• nisaddent—Transfers entries into an NIS+ table

• nistbladm—Creates entries in an NIS+ table

To specify security values other than the default values, insert the -D option into the syntax of those commands, as described in Specifying Access Rights in Commands.

As when setting defaults, you can combine two or more arguments into one line. Remember that column and entry's owner and group are always the same as the table, so you cannot override them.

For example, to use the nismkdir command to create a sales.doc.com directory and override the default access right by granting the owner only read rights you would type:

client% nismkdir -D access=o+r sales.doc.com

Changing Object and Entry Access Rights

The nischmod command operates on the access rights of an NIS+ object or table entry. It does not operate on the access rights of a table column; for columns, use the nistbladm command with the -D option. For all nischmod operations, you must already have modify rights to the object or entry.

Using nischmod to Add Rights

To add rights for an object or entry use:

For object

nischmod class+right object-name

For table entry

nischmod class+right [column-name=value],table-name

For example, to add read and modify rights to the group of the sales.doc.com. directory object you would type:

client% nischmod g+rm sales.doc.com.

For example to add read and modify rights to group for the name=abe entry in the hosts.org_dir.doc.com. table you would type:

client% nischmod g+rm '[name=abe],hosts.org_dir.doc.com.'

Using nischmod to Remove Rights

To remove rights for an object or entry use:

For object

nischmod class-right object-name

For entry

nischmod class-right [column-name=value],table-name

For example, to remove create and destroy rights from the group of the sales.doc.com. directory object you would type:

client% nischmod g-cd sales.doc.com.

For example to remove destroy rights from group for the name=abe entry in the hosts.org_dir.doc.com. table, you would type:

client% nischmod g-d '[name=abe],hosts.org_dir.doc.com.'

Specifying Column Access Rights

The nistbladm command performs a variety of operations on NIS+ tables. Most of these tasks are described in The nistbladm Command. However, two of its options, -c and -u, enable you to perform some security-related tasks:

• The -c option. The -c option allows you to specify initial column access rights when creating a table with the nistbladm command.

• The -u option. The -u option allows you to change column access rights with the nistbladm command.

Setting Column Rights When Creating a Table

When a table is created, its columns are assigned the same rights as the table object. These table level, rights are derived from the NIS_DEFAULTS environment variable, or are specified as part of the command that creates the table. You can also use the nistbladm -c option to specify initial column access rights when creating a table with nistbladm. To use this option you must have create rights to the directory in which you will be creating the table. To set column rights when creating a table use:

nistbladm -c type `columname=[flags] [,access]... tablename'

Where:

• type is a character string identifying the kind of table. A table's type can be anything you want it to be.

• columnname is the name of the column.

• flags is the type of column. Valid flags are:

  • S for searchable

  • I for case insensitive

  • C for encrypted

  • B for binary data

  • X for XDR encoded data

• access is the access rights for this column that you specify using the syntax described in Specifying Access Rights in Commands.

• ... indicates that you can specify multiple columns each of the own type and with their own set of rights.

• tablename is the fully qualified name of the table you are creating.

To assign a column its own set of rights at table creation time, append access rights to each column's equal sign after the column type and a comma. Separate the columns with a space:

column=type, rights column=type, rights column=type, rights

The example below creates a table named depts in the doc.com directory, of type div, with three columns (Name, Site, and Manager), and adds modify rights for the group to the second and third columns:

rootmaster% nistbladm -c div Name=S Site=S,g+m Manager=S,g+m depts.doc.com.

For more information about the nistbladm and the-c option, see Chapter 19, Administering NIS+ Tables.

Adding Rights to an Existing Table Column

The nistbladm -u option allows you to add additional column access rights to an existing table column with the nistbladm command. To use this option you must have modify rights to the table column. To add additional column rights use:

nistbladm -u [column=access,...],tablename

Where:

• column is the name of the column.

• access is the access rights for this column that you specify using the syntax described in Specifying Access Rights in Commands .

• ... indicates that you can specify rights for multiple columns.

• tablename is the fully qualified name of the table you are creating.

Use one column=access pair for each column whose rights you want to update. To update multiple columns, separate them with commas and enclose the entire set with square brackets:

[column=access, column=access, column=access]

The full syntax of this option is described in Chapter 2, NIS+: An Introduction .

The example below adds read and modify rights to the group for the name and addr columns in the hosts.org_dir.doc.com. table.

client% nistbladm -u `[name=g+rm,addr=g+rm],hosts.org_dir..doc.com.'

Removing Rights to a Table Column

To remove access rights to a column in an NIS+ table, you use the -u option as described above in Adding Rights to an Existing Table Column except that you subtract rights with a minus sign (rather than adding them with a plus sign).

The example below removes group's read and modify rights to the hostname column in the hosts.org_dir.doc.com. table.

client% nistbladm -u 'name=g-rm,hosts.org_dir.doc.com.'

Changing Ownership of Objects and Entries

The nischown command changes the owner of one or more objects or entries. To use it, you must have modify rights to the object or entry. The nischown command cannot change the owner of a column, since a table's columns belong the table's owner. To change a column's owner, you must change the table's owner.

Changing Object Owner With nischown

To change an object's owner, use the following syntax:

nischown new-owner object

Where:

• new-owner is the fully qualified user ID of the object's new owner.

• object is the fully qualified name of the object.

Be sure to append the domain name to both the object name and new owner name.

The example below changes the owner of the hosts table in the doc.com. domain to the user named lincoln whose home domain is doc.com.:

client% nischown lincoln.doc.com. hosts.org_dir.doc.com.

Changing Table Entry Owner With nischown

The syntax for changing a table entry's owner uses an indexed entry to identify the entry, as shown below:

nischown new-owner [column=value,...],tablename

Where:

• new-owner is the fully qualified user ID of the object's new owner.

• column is the name of the column whose value will identify the particular entry (row) whose owner is to be changed.

• value is the data value that identified the particular entry (row) whose owner is to be changed.

• ... indicates that you can specify ownership changes for multiple entries.

• tablename is the fully qualified name of the tables containing the entry whose owner is to be changed.

Be sure to append the domain name to both the new owner name and the table name.

The example below changes the owner of an entry in the hosts table of the doc.com. domain to takeda whose home domain is doc.com. The entry is the one whose value in the name column is virginia.

client% nischown takeda.doc.com. '[name=virginia],hosts.org_dir.doc.com.'

Changing an Object or Entry's Group

The nischgrp command changes the group of one or more objects or table entries. To use it, you must have modify rights to the object or entry. The nischgrp command cannot change the group of a column, since the group assigned to a table's columns is the same as the group assigned to the table. To change a column's group owner, you must change the table's group owner.

Changing an Object's Group With nischgrp

To change an object's group, use the following syntax:

nischgrp group object

Where:

• group is the fully qualified name of the object's new group.

• object is the fully qualified name of the object.

Be sure to append the domain name to both the object name and new group name.

The example below changes the group of the hosts table in the doc.com. domain to admins.doc.com.:

client% nischgrp admins.doc.com. hosts.org_dir.doc.com.

Changing a Table Entry's Group With nischgrp

The syntax for changing a table entry's group uses an indexed entry to identify the entry, as shown below (this syntax is fully described in Syntax for Objects and Table Entries).

nischgrp new-group [column=value,...],tablename

Where:

• new-group is the fully qualified name of the object's new group.

• column is the name of the column whose value will identify the particular entry (row) whose group is to be changed.

• value is the data value that identified the particular entry (row) whose group is to be changed.

• tablename is the fully qualified name of the tables containing the entry whose group is to be changed.

• ... indicates that you can specify group changes for multiple entries.

Be sure to append the domain name to both the new group name and the table name.

The example below changes the group of an entry in the hosts table of the doc.com. domain to sales.doc.com. The entry is the one whose value in the host name column is virginia.

client% nischgrp sales.doc.com. '[name=virginia],hosts.org_dir.doc.com.'