nis_objects(3N)

共通属性

NIS+ サービスでは、使用されるオブジェクトの内容を保持するために可変要素レコードとなっている構造体が使用されます。 このようなオブジェクトすべてが持っている一連の属性を定義する共通の構造体を、すべてのオブジェクトで共用します。 nis_object 構造体には以下のメンバーが含まれています。

この構造体の最初のメンバー zo_oid は、当該サーバ上のオブジェクトの当該インスタンスを一意に識別する 64 ビットの数値です。 このメンバーの内容は、オブジェクトの作成時にサーバによって書き込まれ、オブジェクトの変更時にサーバによって変更されます。 このメンバーをオブジェクトの名前およびドメインと一緒に使用すると、 NIS+ ネーム空間全体のオブジェクトを一意に識別することができます。

2 番目のメンバー zo_name には、オブジェクトのリーフ名が入ります。 この名前は `.' (ドット) で終わっていては なりません。 ネーム空間にオブジェクトを作成または追加すると、関数に渡された名前からクライアントライブラリが自動的にこのフィールドとドメイン名フィールドに内容を書き込みます。

zo_domain には当該オブジェクトが属する NIS+ ドメインの名前が入ります。 この情報は、オブジェクトの親関係をキャッシュから追跡する際に効果的です。 このメンバーと一緒に zo_name および zo_oid の両メンバーを使用すると、オブジェクトを一意に識別することができます。 このような構造となっているので、以下のコードを使用すればいつでもオブジェクトの名前を再構築することができます。

zo_owner と zo_group のメンバーにはオブジェクトの主所有者とグループ所有者の NIS+ 名がそれぞれ入ります。 どちらの名前も NIS+ の完全修飾名でなければ なりません。 ただし、各名前を個別に使用しても、それが表すオブジェクトを直接指示することはできません。 これは、 NIS+ が発信する情報を保存するとき、 NIS+ 自体を使用するためです。

zo_owner メンバーには、 principal.domain の形式で NIS+ の完全修飾名が入ります。 この名前を NIS+ 主体名と呼び、資格テーブルにある認証情報を識別する際に使用されます。 サーバは以下の形式の検索照会を作成します。

principal で使用される、その principal 用の全 RPC 認証情報が、照会によってサーバへ戻ります。 RPC 要求がサーバに届くと、その要求から認証の種類が抽出されて、クライアントの NIS+ 主体名の検出に使用されます。 例えば、クライアントが AUTH_DES の認証を使用している場合は、要求を出したユーザーのネットワーク名つまり ネット名 が認証の認定情報に含まれます。 このネット名は以下の形式となっています。

その後で NIS+ サーバは認定データベースに関する照会を以下の形式で作成します。

この照会により、最初のカラムに主体名が入ったエントリが戻ります。 この NIS+ 主体名は、NIS+ オブジェクトのアクセスを制御するために使用されます。

オブジェクトのグループ所有者は別の方法で取り扱われます。 グループ所有者のメンバーはオプション (使用しない場合は空文字列) ですが、使用する場合には完全修飾名を指定してください。 グループ名の形式は以下の通りです。

サーバはこの名前を以下の形式の名前にマッピングします。

このマッピングの目的は、NIS+ グループ名がユーザー指定のドメイン名またはテーブル名と衝突しないようにすることです。 例えば、ドメインが engineering.foo.com. という名前の場合、これと同じ名前の NIS+ グループ名を engineering のメンバーとして表すには、マッピングしない限り不可能です。グループの内容はオブジェクトの zo_owner 名で使用される NIS+ 主体名のリストです。 詳細は、 nis_groups(3N) を参照してください。

zo_access メンバーには、当該オブジェクトに割り当てられたアクセス権のビットマスクが入ります。 4 つのアクセス権が定義されており、他にも将来のために 4 つが予約され、この値がゼロのときアクセス権が与えられます。 この 8 つのアクセス権は、4 つのカテゴリのクライアントに与えることができます。 この 4 つのカテゴリとは、オブジェクトの所有者、オブジェクトのグループ所有者、認証されたすべてのクライアント (world)、認証されていないすべてのクライアント (nobody) です。 ``nobody'' に与えられるアクセス権は、実際は、認証されたクライアントと認証されていないクライアントのだれにでも与えられるアクセス権であることに注意してください。

zo_ttl メンバーには、該当オブジェクトがキャッシュ内に置かれる「寿命」の秒数が入ります。 この値はオブジェクトの有効期間 (ttl) と呼ばれます。 この値はグループオブジェクトやディレクトリ (ドメイン) オブジェクトの場合特に重要です。 オブジェクトがキャッシュされると、現在時刻が zo_ttl の値に加算されます。 その後、キャッシュされたオブジェクトが使用されるたびに、 zo_ttl の時間が現在時刻と比較されます。 現在時刻が zo_ttl の時間を超えると、オブジェクトは期限切れとなり、キャッシュコピーは使用されません。

ttl の設定を工夫してください。 ttl はオブジェクトの「半生」、つまりオブジェクトが変更されるまでの時間の半分と考えることができます。 ttl を大きな値に設定した場合は、オブジェクトが長い時間キャッシュに存在するので有利です。 大きな値を設定した場合の欠点は、オブジェクトに変更があったとき、キャッシュがそのオブジェクトの古いコピーをフラッシュするのに長い時間がかかることです。 小さい値に設定した場合は、この欠点と利点が逆になります。 一般に、毎日変更されるようなものは、値を 43200 (12 時間) に設定すると妥当であり、週ごとに変更されるようなものは、 3024000 に設定するとよいでしょう。 値を 0 に設定するとただちに期限切れとなるので、オブジェクトはキャッシュされません。

この共用体は、 zo_type に入っている型の値に基づいて区分されます。 現在、NIS+ サービスでは、ディレクトリ、リンク、グループ、テーブル、エントリ、プライベートの 6 つの型のオブジェクトが定義されています。

各オブジェクト型により、型固有のデータが入る構造体が決まります。 最も単純なものはプライベートオブジェクトで、オクテットの可変長配列を含みます。 オブジェクトの所有者だけがプライベートオブジェクトの内容を理解できます。 次のセクションでは、その他の 5 つのオブジェクト型を詳しく説明します。

ディレクトリオブジェクト

オブジェクトの 1 つ目の型はディレクトリ オブジェクトです。 このオブジェクトの可変部は、以下のように定義します。 PP

メインの構造体には do_name、 do_type、 do_servers、 do_ttl、 do_armask の 5 つの主メンバーが含まれます。 クライアントライブラリがディレクトリが指定するサーバとネットワーク接続を行うには、 do_servers 構造体の情報だけで十分です。

do_name メンバーには、ドメインに対して有効なネームサービスの型で、認識可能なフォーマットで表わされたディレクトリまたはドメインの名前が入ります。 NIS+ ドメインの場合は、zo_name メンバーと zo_domain メンバーで構成される名前と同じになります。 その他のネームサービスの場合は、そのネームサービスで認識できる名前となります。 例えば、NIS+ ディレクトリ eng.hp.com.「配下」にある X.500 ネーム空間を記述するディレクトリオブジェクトの場合には、名前に ``/C=US, /O=Hewlett-Packard, /OU=Engineering/'' を含めることができます。 記述されているネームサービスの型は、メンバー do_type の値で判断されます。

do_servers 構造体には 2 つのメンバーがあります。1 つは do_servers_val で、これは nis_server 構造体の配列です。もう 1 つは do_servers_len で、これは配列中のセル数を示します。 nis_server 構造体は、ネームサービスを提供するネットワーク上のマシンに、ネームサービスを使用しないで接続する場合の情報が入ります。 NIS+ サーバーの場合、この情報には、 name で指定されたマシン名、 pkey で指定された認証用のパブリックキー、可変長配列のエンドポイントがあり、 それぞれが指定されたマシンの rpcbind デーモンのネットワークエンドポイントを表します。 クライアントライブラリはこれらのアドレスを使用して、クライアントとサーバの両方で通信可能な相手に接続します。そして、そのサーバが使用する物理アドレスを得るために rpcbind デーモンを参照します。

do_servers リストの先頭のサーバは常にディレクトリのマスターサーバであることに注意してください。

key_type フィールドは、pkey netobj (ネットワークオブジェクト構造体の定義については /usr/include/rpc/xdr.h を参照) に保存されているキーの型を記述します。 現在サポートされている型は、パブリックキーなしの NIS_PK_NONE と、 Diffie-Hellman 方式のパブリックキーの NIS_PK_DH です。

do_ttl メンバーには、共通属性の zo_ttl メンバーのコピーが含まれます。 コピーを使用する理由は、キャッシュマネージャはディレクトリオブジェクトの可変部だけをキャッシュするからです。

do_armask 構造体には 2 つのメンバーがあります。 1 つは do_armask_val で、 これは oar_mask 構造体の配列です。もう 1 つは do_armask_len で、これは配列中のセル数を示します。 oar_mask 構造体にも 2 つのメンバーがあり、 oa_rights は oa_otype の型のオブジェクトに対して許可されるアクセス権を示します。 このアクセス権が配列中にあると、ディレクトリ内の特定のオブジェクト型に対してそのアクセス権が使用されます。

ディレクトリ内に含まれているオブジェクトに対するアクセス権の認可は、実際には 2 つの層になっています。 ディレクトリオブジェクト自体が特定のアクセス権を認可 (ディレクトリを表す nis_object 構造体の zo_access メンバーを使用) していると、そのディレクトリ内のすべてのオブジェクトにそのアクセスが許可されることになります。 そうでない場合は、 do_armask 構造体が調べられ、指定したオブジェクト型のアクセス権が確認されます。 このような方式になっているので、ネーム空間の管理者はそれぞれのオブジェクト型を個別に設定できます。例えば、テーブルを作成するポリシーと、他のディレクトリを作成するポリシーを区別することができます。 詳細は、 nis+(1) を参照してください。

リンクオブジェクト

リンクオブジェクトは、ネーム空間内で 別名 、つまり、シンボリックリンクを提供します。このオブジェクトの可変部は以下のように定義します。

li_rtype メンバーには、リンクされるオブジェクトの型が入ります。 リンクされるオブジェクトは変更や削除されることがあるので、これは単にヒントに過ぎません。 メンバー li_name にはオブジェクト (テーブル、その他) の完全修飾名を指定します。

NIS+ リンクは、NIS+ ネーム空間内の他のオブジェクトをポイントすることも、 NIS+ テーブル内のエントリをポイントすることもできます。 リンクでポイントされているオブジェクトがテーブルで、メンバー li_attrs に指定されている属性 (インデックス名 / 値の対) の数がゼロ以外であると、このリンクではテーブルが検索されます。 そして、指定された検索パターンと一致するエントリがすべて戻されます。 ここで、フラグ FOLLOW_LINKS の指定がない限り、 nis_lookup(3N) 関数は常にエントリ以外のオブジェクトを戻すことに注意してください。

グループオブジェクト

グループオブジェクトには、NIS+ 主体のメンバーシップリストが含まれています。 グループオブジェクトの可変部は以下のように定義します。 PP

gr_flags メンバーには、現在使用されていないフラグが入ります。 gr_members 構造体には、主体のリストが入ります。 グループオブジェクトの詳しい操作方法については、 nis_groups(3N). を参照してください。

テーブルオブジェクト

NIS+ テーブルオブジェクトは YP マップと似ています。 ただし、アクセス制御と NIS+ 対応の変数のスキーマは異なります。 テーブルオブジェクトのデータ構造は、以下のように定義します。

ta_type メンバーには、当該テーブル内のエントリ型を示す文字列が入ります。 NIS+ では、この文字列を自由に設定できます。 ただし、 NIS+ サービスがエントリをテーブルに追加する際には、 エントリがこのメンバーで指定されているテーブルと同じ「型」となっているかをチェックします。

ta_cols 構造体には 2 つのメンバーがあります。ta_cols_val は table_col 構造体の配列です。この配列の長さは、テーブルのカラム数によって異なります。この長さはテーブルの作成時に定義し、 ta_cols_len に保存します。ta_maxcol にもテーブルのカラム数が入りますが、常に ta_cols_len と同じ長さになります。いったんテーブルを作成すると、この長さのフィールドを変更できません。

ta_sep の文字は、クライアントアプリケーションでテーブル内のエントリを印刷するときに使用する区切り文字を含みます。この文字は、通常、空白 (`` '') かコロン (``:'') のどちらかです。

ta_path の文字列は、テーブルの連結パスを定義します。 この文字列は、該当テーブルの検索でどのエントリも一致しない場合に使用され、検索対象となるテーブルの完全修飾名をコロンで区切って特定の順序でリストしたものです。 このパスは、 nis_list() の呼び出しでフラグ FOLLOW_PATH を指定したときにのみ使用されます。 フラグについては、 nis_tables(3N) を参照してください。

サービスは型をチェックするだけでなく、エントリを追加する前に、そのカラム数がテーブルのカラム数と同じであるかもチェックします。

各カラムには、 tc_name にある名前、 tc_flags にある一連のフラグ、tc_rights にある一連のアクセス権が関連付けられています。 名前は、そのカラムの内容を示すものでなければなりません。

TA_BINARY フラグは、そのカラム内のデータがテキストではなくバイナリであることを示します。 バイナリデータを含んだカラムは、検索されません。 TA_CRYPT フラグは、ネットワーク上を送信する場合に、カラム内の情報を前もって暗号化する必要があることを示します。 エクスポート版の NIS+ では、このフラグは効力がありません。 TA_XDR フラグは、カラム内のデータが XDR プロトコルによってコード化されていることをクライアントアプリケーションに指示します。 XDR フラグを指定する際には、 TA_BINARY フラグも一緒に指定する必要があります。 さらに、慣例的に TA_XDR フラグが設定されているカラム名を、そのデータをデコードする XDR 関数の名前にします。

TA_SEARCHABLE フラグは、カラムの内容が検索可能であることを示します。 検索可能なカラムの内容はテキストデータでなければならず、それに関連した名前をつける必要があります。 TA_CASE フラグは、大文字と小文字を無視してこのカラムを検索させます。 テーブル内には、少なくとも検索可能なカラムが 1 つはあるようにしてください。 また、検索可能なカラムすべての内容を組み合わせたものが、テーブル内でユニークなエントリとなるようにする必要があります。

エントリオブジェクト

エントリオブジェクトはテーブルに保存されます。 エントリデータを定義するための構造体は、以下の通りです。

en_type メンバーには、エントリのデータ型を示す文字列が入ります。 NIS+ サーバは、この文字列とテーブルオブジェクトに指定された型文字列を比較し、違っている場合はそのエントリの更新や変更を許可しません。

en_cols 構造体には en_cols_len と en_cols_val の 2 つのメンバーがあります。en_cols_val は entry_col 構造体の配列です。 en_cols_len には en_cols_val 配列のセル数が入り、テーブル内のカラム数に反映されます。この値は、エントリが格納されているテーブルの table_obj.ta_cols.ta_cols_len メンバーと常に同じ値になります。

entry_col 構造体には、エントリの各カラムごとの値に関する情報が入ります。 ec_value には、特定の値に関する情報が入ります。これには 2 つのメンバーがあり、 ec_value_val には値自体が、 ec_value_len には値の長さがバイトで入ります。 entry_col にもメンバー ec_flags があり、エントリ用の一連のフラグが入ります。

ec_flags のフラグは、主に、テーブルにエントリを追加したり、テーブルのエントリを変更する場合に使用されます。 EN_CRYPT フラグが設定されているカラムはすべて、ネットワークで送信する前に暗号化されます。 EN_BINARY フラグが設定されているカラムは、バイナリデータが入っているものとみなされます。 サーバは、エントリを追加する前に、テーブルオブジェクト中のカラムでバイナリデータが指定されているかを確認します。 テーブル中のエントリを変更した場合、変更のあるカラムだけをサーバへ送ります。 変更対象であることをサーバに指示するために、変更する各カラムに EN_MODIFIED フラグを設定する必要があります。