System Administration Guide: Naming and Directory Services (FNS and NIS+)

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 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:

Access Rights—Review

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

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:

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.

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

Table, Column, and Entry Security

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

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, 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:

Table 15–1 Table, Column, Entry Example 1

 

Nobody 

Owner 

Group 

World 

Table Access Rights: 

----

r---

----

----

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:

Table 15–2 Table, Column, Entry Example 2

 

Nobody 

Owner 

Group 

World 

Table Access Rights: 

----

r---

----

----

Entry-2 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:

Table 15–3 Table, Column, Entry Example 3

 

Nobody 

Owner 

Group 

World 

Table Access Rights: 

----

r---

----

----

Entry-2 Access Rights: 

----

----

r---

----

Column-1 Access Rights: 

----

----

----

r---

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).

Table 15–4 Table, Column, Entry Example 4

 

Col 1 

Col 2 

Col 2 

Entry-1 

contents 

*NP*

*NP*

Entry-2 

contents 

contents 

contents 

Entry-3 

contents 

*NP*

*NP*

Entry-4 

contents 

*NP*

*NP*

Entry-5 

contents 

*NP*

*NP*

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:

Table 15–5 Access Rights and Levels and the Objects They Act Upon

 

Directory 

Table 

Column 

Entry 

Read 

List directory contents 

View table contents 

View column contents 

View entry (row) contents 

Create 

Create new directory or table objects 

Add new entries (rows) 

Enter new data values in a column 

Enter new data values in an entry (row) 

Modify 

Move objects and change object names 

Change data values anywhere in table 

Change data values in a column 

Change data values in an entry (row) 

Destroy 

Delete directory objects such as tables 

Delete entries (rows) 

Delete data values in a column 

Delete data values in an entry (row) 

Read Rights

Create Rights

Modify Rights

Destroy Rights

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:

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:

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

Diagram shows order of access rights, starting with nobody


Note –

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.

Table 15–6 Default Access Rights

Nobody 

Owner 

Group 

World 

read 

read 

read 

modify 

create 

destroy 

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.


Note –

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:

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.

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.

Table 15–7 Access Rights Syntax—Class

Class 

Description 

n

Nobody: all unauthenticated requests 

o

The owner of the object or table entry 

g

The group owner of the object or table entry 

w

World: all authenticated principals 

a

All: shorthand for owner, group, and world (this is the default) 

Table 15–8 Access Rights Syntax—Operator

Operator 

Description 

+

Adds the access rights specified by right

-

Revokes the access rights specified by right

=

Explicitly changes the access rights specified by right; in other words, revokes all existing rights and replaces them with the new access rights.

Table 15–9 Access Rights Syntax—Rights

Right 

Description 

r

Reads the object definition or table entry 

m

Modifies the object definition or table entry 

c

Creates a table entry or column 

d

Destroys a table entry or column 

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

Table 15–10 Class, Operator, and Rights Syntax—Examples

Operations 

Syntax 

Add read access rights to the owner class

o+r

Change owner. group, and world classes' access rights to modify only from whatever they were before 

a=m

Add read and modify rights to the world and nobody classes 

wn+m

Remove all four rights from the group, world, and nobody classes 

gwn-rmcd

Add create and destroy rights to the owner class and add read and modify rights to the world and nobody classes 

o+cd,wn+rm

Syntax for Owner and Group


principalname

For group


groupname.domainname

Syntax for Objects and Table Entries

Objects and table entries use different syntaxes.

For objects


objectname

For table entries


columnname=value],tablename

Note –

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:

Table 15–11 Object and Table Entry—Examples

Type 

Example 

Object 

hosts.org_dir.sales.doc.com.

Table entry 

`[uid=33555],passwd.org_dir.Eng.doc.com.'

Two-value table entry 

`[name=sales,gid=2],group.org_dir.doc.com.'

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

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.

Table 15–12 The Seven NIS+ Default Values and nisdefaults Options

Default 

Option 

From 

Description 

Domain 

-d

/etc/defaultdomain

Displays the home domain of the machine from which the command was entered. 

Group 

-g

NIS_GROUP environment variable

Displays the group that would be assigned to the next object created from this shell. 

Host 

-h

uname -n

Displays the machine's host name. 

Principal 

-p

gethostbyname()

Displays the fully qualified user name or host name of the NIS+ principal who entered the nisdefaults command.

Access Rights 

-r

NIS_DEFAULTS environment variable

Displays the access rights that will be assigned to the next object or entry created from this shell. Format: ----rmcdr---r---

Search path 

-s

NIS_PATH environment variable

Displays the syntax of the search path, which indicate the domains that NIS+ will search through when looking for information. Displays the value of the NIS_PATH environment variable if it is set.

Time-to-live 

-t

NIS_DEFAULTS environment variable

Displays the time-to-live that will be assigned to the next object created from this shell. The default is 12 hours. 

All (terse) 

-a

 

Displays all seven defaults in terse format. 

Verbose 

-v

Display specified values in verbose mode. 

 

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


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.

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:

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:

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:

Table 15–13 Changing Defaults—Examples

Tasks 

Examples 

This command grants owner read access as the default access right. 

client% setenv NIS_DEFAULTS access=o+r

This command sets the default owner to be the user abe whose home 

domain is doc.com. 

client% setenv NIS_DEFAULTS owner=abe.doc.com.

This command combines the first two examples on one code line. 

client% setenv NIS_DEFAULTS access=o+r:owner=abe.doc.com.

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:

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:

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:

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:

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:

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:

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:

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:

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.'