The NIS+ service uses a variant record structure to hold the contents of the objects that are used by the NIS+ service. These objects all share a common structure that defines a set of attributes that all objects possess. The nis_object structure contains the following members:
|
typedef char *nis_name;
struct nis_object {
nis_oid zo_oid;
nis_name zo_name;
nis_name zo_owner;
nis_name zo_group;
nis_name zo_domain;
uint_t zo_access;
uint32_t zo_ttl;
objdata zo_data;
};
|
In this structure, the first member zo_oid, is a 64 bit number that uniquely identifies this instance of the object on this server. This member is filled in by the server when the object is created and changed by the server when the object is modified. When used in conjunction
with the object's name and domain it uniquely identifies the object in the entire NIS+ namespace.
The second member, zo_name, contains the leaf name of the object. This name is never terminated with a `.' (dot). When an object is created or added to the namespace, the client library will automatically fill in this field and the domain name from the name that was passed to
the function.
zo_domain contains the name of the NIS+ domain to which this object belongs. This information is useful when tracking the parentage of an object from a cache. When used in conjunction with the members zo_name and zo_oid, it uniquely identifies
an object. This makes it possible to always reconstruct the name of an object by using the code fragment
|
sprintf(buf,"%s.%s", obj->zo_name, obj->zo_domain);
|
The zo_owner and zo_group members contain the NIS+ names of the object's principal owner and group owner, respectively. Both names must be NIS+ fully qualified names. However, neither name can be used directly to identify the object they represent. This stems
from the condition that NIS+ uses itself to store information that it exports.
The zo_owner member contains a fully qualified NIS+ name of the form principal.domain. This name is called a NIS+ principal name and is used to identify authentication information in a credential table. When the server constructs a search query of the
form
|
[cname=principal],cred.org_dir.domain.
|
The query will return to the server credential information about principal for all flavors of RPC authentication that are in use by that principal. When an RPC request is made to the server, the authentication
flavor is extracted from the request and is used to find out the NIS+ principal name of the client. For example, if the client is using the AUTH_DES authentication flavor, it will include in the authentication credentials the network name or netname
of the user making the request. This netname will be of the form
The NIS+ server will then construct a query on the credential database of the form
|
[auth_name=netname,auth_type=AUTH_DES],cred.org_dir.domain.
|
This query will return an entry which contains a principal name in the first column. This NIS+ principal name is used to control access to NIS+ objects.
The group owner for the object is treated differently. The group owner member is optional (it should be the null string if not present) but must be fully qualified if present. A group name takes the form
which the server then maps into a name of the form
The purpose of this mapping is to prevent NIS+ group names from conflicting with user specified domain or table names. For example, if a domain was called engineering.foo.com., then without the mapping a NIS+ group of the same name to represent members of engineering would
not be possible. The contents of groups are lists of NIS+ principal names which are used exactly like the zo_owner name in the object. See nis_groups(3NSL) for more
details.
The zo_access member contains the bitmask of access rights assigned to this object. There are four access rights defined, and four are reserved for future use and must be zero. This group of 8 access rights can be granted to four categories of client. These categories are the
object's owner, the object's group owner, all authenticated clients (world), and all unauthenticated clients (nobody). Note that access granted to ``nobody'' is really access granted to everyone, authenticated and unauthenticated clients.
The zo_ttl member contains the number of seconds that the object can ``live'' in a cache before it is expired. This value is called the time to live for this object. This number is particularly important on group and directory (domain) objects. When an object is cached, the current
time is added to the value in zo_ttl. Then each time the cached object is used, the time in zo_ttl is compared with the current time. If the current time is later than the time in zo_ttl the object is said to have expired and the cached copy should
not be used.
Setting the TTL is somewhat of an art. You can think of it as the ``half life'' of the object, or half the amount of time you believe will pass before the object changes. The benefit of setting the ttl to a large number is that the object will stay in a cache for
long periods of time. The problem with setting it to a large value is that when the object changes it will take a long time for the caches to flush out old copies of that object. The problems and benefits are reversed for setting the time to a small value. Generally setting the value to 43200 (12 hrs)
is reasonable for things that change day to day, and 3024000 is good for things that change week to week. Setting the value to 0 will prevent the object from ever being cached since it would expire immediately.
The zo_data member is a discriminated union with the following members:
|
zotypes zo_type;
union {
struct directory_obj di_data;
struct group_obj gr_data;
struct table_obj ta_data;
struct entry_obj en_data;
struct link_obj li_data;
struct {
uint_t po_data_len;
char *po_data_val;
} po_data;
} objdata_u;
|
The union is discriminated based on the type value contained in zo_type. There six types of objects currently defined in the NIS+ service. These types are the directory, link, group, table, entry, and private types.
|
enum zotypes {
BOGUS_OBJ = 0,
NO_OBJ = 1,
DIRECTORY_OBJ = 2,
GROUP_OBJ = 3,
TABLE_OBJ = 4,
ENTRY_OBJ = 5,
LINK_OBJ = 6,
PRIVATE_OBJ = 7
};
typedef enum zotypes zotypes;
|
All object types define a structure that contains data specific to that type of object. The simplest are private objects which are defined to contain a variable length array of octets. Only the owner of the object is expected to understand the contents of a private object. The following section
describe the other five object types in more significant detail.
|