Chapter 15Administering 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:
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
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.
|
Previous