パート II NIS+ の紹介と概要

パート II では、NIS+ について説明します。

• 第 3 章「NIS+ の紹介」

• 第 4 章「NIS+ の名前空間」

• 第 5 章「NIS+ のテーブルと情報」

• 第 6 章「セキュリティの概要」

第 3 章 NIS+ の紹介

この章では、NIS+ の概要を述べます。

• 「NIS+ について」

• 「NIS+ のメリット」

• 「NIS+ と NIS の違い」

• 「NIS+ のセキュリティ」

• 「NIS+ とネームサービススイッチ」

• 「Solaris 1.x と NIS 互換モード」

• 「NIS+ の管理コマンド」

• 「NIS+ の API」

NIS+ および DNS 名前空間を設定する方法については、『Solaris ネーミングの設定と構成』を参照してください。用語や略語の定義については、用語集を参照してください。

NIS+ について

NIS+ は NIS によく似たネットワークネームサービスですが、より多くの機能を備えています。NIS+ は NIS を機能拡張したものではなく、新しいソフトウェアプログラムとなっています。

NIS+ ネームサービスは、ネットワークがどのような構造であっても、その周囲を取り巻くことにより、サービスを設置した組織の形態に適合するように設計されています。

NIS+ はワークステーションのアドレス、セキュリティ情報、メール情報、Ethernet インタフェース、ネットワークサービスなどの情報を 1 カ所に格納して、ネットワーク上のすべてのワークステーションからアクセスできるようにします。このように構成されたネットワーク情報を、NIS+「名前空間」と呼びます。

NIS+ 名前空間は階層構造となっていて、UNIX のディレクトリファイルシステムによく似ています。階層構造になっていることから、NIS+ 名前空間を企業組織の階層に合わせて構成できます。名前空間の情報のレイアウトは、その「物理的」構成とは無関係です。したがって、NIS+ 名前空間は、独立して管理できる複数のドメインに分割できます。クライアントは、適切なアクセス権があれば、自分のドメインだけではなく、ほかのドメインの情報にもアクセスできます。

NIS+ はクライアントサーバーモデルを使用して、NIS+ 名前空間に情報を格納し、またその情報にアクセスできます。各ドメインは複数のサーバーによってサポートされます。最も重要なサーバーは「マスター」サーバーと呼ばれ、バックアップサーバーは「複製」サーバーと呼ばれます。ネットワーク情報は、内部 NIS+ データベース内にある 16 個の標準 NIS+ テーブルに格納されています。マスターサーバーと複製サーバーは、共に NIS+ サーバーソフトウェアを実行し、NIS+ テーブルのコピーを管理します。マスターサーバー上の NIS+ データの変更は、複製サーバーにも自動的に伝達されます。

NIS+ には、名前空間の構造とその情報を保護するために、高度なセキュリティシステムが組み込まれています。NIS+ は認証 (authentication) と承認 (authorization) を使用して、クライアントの情報要求に応えるべきかどうかを検証します。「認証」とは、情報の要求者がネットワークの正当なユーザーであるかどうかを判定することです。「承認」とは、要求された情報に関して特定のユーザーが入手または変更を許可されているかどうかを判定することです。

Solaris のクライアントは、ネームサービススイッチ (/etc/nsswitch.conf ファイル) を使用して、ワークステーションがどこからネットワーク情報を取り出すかを決定します。この種の情報はローカル側の /etc ファイルや、NIS、DNS、NIS+ に格納されます。ネームサービススイッチでは、情報の種類ごとに異なるソースを指定できます。

NIS+ のメリット

NIS と比較すると、NIS+ には次のようなメリットがあります。

• 安全性の高いデータアクセス

• 階層構造を使用した分散型のネットワーク管理

• 非常に大きな名前空間の管理

• 異なるドメインにあるリソースへのアクセス

• 増分 (incremental) 更新

「NIS+ のセキュリティ」で説明したセキュリティシステムを使用すれば、特定のテーブルの個々のエントリに対する特定のユーザーのアクセスを制御できます。このようなセキュリティ方式では、システムを安全に維持でき、しかも NIS+ 名前空間全体またはテーブル全体が損傷する危険性がなく、管理業務を広く分散させることができます。

NIS+ の階層構造により、1 つの名前空間に複数のドメインを置くことができます。ドメインに分割することにより、管理が容易になります。個々のドメインは完全に独立して管理できるため、システム管理者の負担が軽減され、非常に大きな名前空間の管理責任から解放されます。このように、セキュリティシステムを分散型のネットワーク管理と組み合わせることによって、管理作業の負担を分担することができます。

ドメインが個別に管理されているとしても、すべてのクライアントに名前空間内のすべてのドメインの情報を参照するアクセス権を与えることができます。クライアントは自分のドメイン内のテーブルしか見ることができないため、クライアントがほかのドメイン内のテーブルにアクセスするには、そのテーブルについて明示的にアドレスを指定しなければなりません。

増分更新とは、名前空間内での情報の高速の更新を意味します。ドメインは独立して管理されるため、マスターサーバーテーブルへの変更は、名前空間全体にではなく、その複製サーバーだけに伝達しますが、伝達が行われると、これらの変更はすぐに名前空間全体で有効になります。

NIS+ と NIS の違い

「NIS+」と「NIS」はいくつかの点で違いがあります。NIS+ は多くの新機能を備え、同じような概念でも用語が異なっています。わからない用語があれば用語集を参照してください。NIS と NIS+ の主な相違点を表 3-1 にまとめます。

NIS+ は NIS に代わるものとして設計されました。NIS は、1980 年代に普及していたクライアントサーバーコンピューティングネットワークの管理要件に応えるものです。その当時のクライアントサーバーネットワークは、通常、クライアント数が数百を超えることはなく、多目的サーバーの数もわずかでした。これらのネットワークは数カ所のリモートサイトを結んでいるだけであり、しかもユーザーに専門知識があり信頼できたため、セキュリティを必要としませんでした。

しかしクライアントサーバーネットワークは 1980 年代半ば頃から急速な成長を遂げました。現在では、世界中のサイトに配置された 10〜100 台の専用サーバーにサポートされた 100〜10,000 台のマルチベンダークライアントが存在し、複数の公衆網に接続されています。さらに、ネットワークが格納する情報は、NIS の時代よりもはるかに急速に変化しています。このようなネットワークの規模と複雑性に対処するため、新しい管理方式が必要になりました。NIS+ はこれらの必要性に焦点をあてて設計されました。

NIS の名前空間は、フラットな状態で管理機能を集中管理しています。1990 年代に入りネットワークはスケーラビリティと管理の分散化を求めるようになったため、NIS+ の名前空間は DNS の場合のように階層ドメインをベースに設計されました。

たとえば、図 3-1 は doc という名前の親ドメインと、sales と manf という 2 つのサブドメインを持つ会社の例を示しています。

図 3-1 階層型ドメインの例

これによって NIS+ は、小規模から大規模まで、広い範囲のネットワークで使用できます。また、NIS+ のサービスを組織の成長に適合させることもできます。たとえば、ある会社が 2 つの部門に分かれた場合、それに対する NIS+ の名前空間を 2 つのドメインに分割し、これらを自律的に管理できます。インターネットがドメインの管理を下のレベルに委譲するように、NIS+ のドメインも程度の差はあっても互いに独立して管理できます。

NIS+ は DNS と似たドメイン階層を使用しますが、NIS+ のドメインは DNS のドメインよりずっと多くの情報を持っています。DNS のドメインは、そのクライアントの名前とアドレスの情報を格納するだけです。一方 NIS+ のドメインには、組織の一部の中でのワークステーション、ユーザー、およびネットワークサービスについての「情報」が集められています。

ドメインをこのように分割することで、管理はより自律的になり、規模が拡大した場合にもうまく対処できますが、情報へのアクセスが以前より困難になることもありません。クライアントは他のドメインの情報にも、同じドメインと同じようにアクセスできます。あるドメインを別のドメインの内部から管理することもできます。

NIS+ のクライアントサーバーの配置は、各ドメインが一組のサーバーによってサポートされるという点では、NIS や DNS の配置と似ています。 主サーバーは「マスター」サーバーと呼ばれ、バックアップサーバーは「複製」サーバーと呼ばれます。マスターサーバーと複製サーバーは、両方とも NIS+ のサーバーソフトウェアを実行し、NIS+ テーブルのコピーを保持します。主サーバーはオリジナルのテーブルを、バックアップサーバーはコピーを、それぞれ格納します。

しかし NIS+ は、NIS とはまったく異なる更新方式を使用します。NIS が開発された当時は、格納される情報の型はめったに変化しなかったため、NIS は安定性に重点を置いた更新方式によって開発されました。NIS テーブルの更新は手作業で処理され、大規模な組織では、すべての複製サーバーへの伝達に 1 日以上かかることもあります。この原因の一つは、マップ内の情報が変化するたびにマップ全体を再作成して伝達しなければならなかったからです。

しかし NIS+ は、複製サーバーに対する「増分 (incremental)」更新が可能です。マスターサーバー上での変更は依然として必要ですが、いったん変更すれば、複製サーバーに自動的に伝達され、すぐに名前空間全体から使用できるようになります。マップを「作成」したり、伝達を待つ必要はありません。

NIS+ のドメイン構造、サーバー、およびクライアントの詳細は、第 4 章「NIS+ の名前空間」を参照してください。

NIS+ のドメインは、次に示すようなネームサービススイッチを使用して、その NIS+ クライアントを経由してインターネットに接続できます (「NIS+ とネームサービススイッチ」を参照)。このクライアントが DNS のクライアントでもある場合、自分のスイッチ構成ファイルを設定して、NIS+ テーブルだけでなく、DNS ゾーンファイルまたは NIS マップ内の情報を検索できます。

NIS+ は、マップやゾーンファイルではなく、「テーブル」に情報を格納します。NIS+ は 16 種類のあらかじめ定義したテーブル (つまり「システム」テーブル) を提供します。

各テーブルにはそれぞれ異なる情報が格納されています。たとえば、hosts テーブルにはワークステーションアドレスについての情報が、password テーブルにはネットワークのユーザーについての情報が格納されています。

NIS+ のテーブルは、NIS で使用されるマップと比較して 2 つの点で大きく改良されています。第 1 に、NIS+ のテーブルは、最初の列 (キーと呼ばれることもある) だけではなく、任意の列ごとにアクセスできます。これによって、NIS で使用される hosts.byname や hosts.byaddr マップなどの二重マップが必要なくなります。第 2 に、NIS+ のテーブル内の情報は、3 つの細分化されたレベルでアクセスし、操作できます。テーブルレベル、エントリレベル、および列レベルです。NIS+ のテーブルとそこに格納されている情報については、第 5 章「NIS+ のテーブルと情報」で説明します。

NIS 管理者は、以下に示す原則および条件下で NIS を NIS+ と共に使用できます。

• 同一ドメインに NIS サーバーと NIS+ サーバーの両方が存在する

  NIS 管理者は同一ドメインで NIS サーバーと NIS+ サーバーの両方を動作させることは可能ですが、このような動作を長時間行わせることは望ましくありません。一般に、同一ドメイン内での NIS サーバーと NIS+ サーバーを両方使用するのは、NIS から NIS+ への短い移行期間だけに制限するべきです。

• サブドメイン

  NIS 管理者のルートドメインのマスターサーバーで NIS+ が動作している場合は、NIS 管理者は、すべてのサーバーで NIS が動作しているサブドメインを設定できます。NIS 管理者のルートドメインのマスターサーバーで NIS が動作している場合は、NIS 管理者はサブドメインの設定はできません。

• 同一ドメインに複数のワークステーションが存在する

  • 同一ドメイン内のサーバーで NIS+ が動作している場合は、NIS+、NIS、または /etc ファイルを使ってネームサービス情報を取得できるように、ドメイン内の各マシンを設定できます。NIS+ サーバーが NIS クライアントのニーズを満たすには、この NIS+ サーバーが NIS 互換モードで動作している必要があります。

  • 同一ドメイン内の異なる複数のサーバーで NIS が動作している場合は、NIS または /etc ファイルを使ってネームサービス情報を取得できるように、このドメイン内の各マシンを設定することができます (各マシンは NIS+ の使用不可)。

  さまざまなネームサービス情報を取得するためにワークステーションがどのサービスを使用するかは、そのマシンの nsswitch.conf ファイルで制御されます。このファイルは、「スイッチ」ファイルと呼ばれています。詳細は、第 2 章「ネームサービススイッチ」を参照してください。

NIS+ のセキュリティ

NIS+ は、「承認と認証」という相補的なプロセスによって、名前空間の構造と格納する情報を保護します。

• 「承認」は、名前空間の構成要素に対して、「誰がどのような操作を行えるのか」ということを指定することです。すべての構成要素について行われます。

• 「認証」は、名前空間へのアクセス要求をしている NIS+「主体」(プロセス、マシン、ルート、ユーザーなど) が「正当なものであるかどうかを確認」することです。「正当な NIS+ 主体」とは、NIS+「資格」を持っているものを指します。名前空間へのアクセスが行われると、必ずその要求者 (主体) の認証が行われます。

NIS+ が要求どおりの動作をするのは、「主体が認証されていて (正当な資格を持っていて)、要求された操作が、該当する構成要素において承認されている」という場合のみです。資格がない (または完全でない)、要求された操作が承認されていないという場合、NIS+ はアクセス要求を拒否します。NIS+ セキュリティシステムの詳細は、第 6 章「セキュリティの概要」パート II「NIS+ の紹介と概要」を参照してください。

NIS+ とネームサービススイッチ

NIS+ は、「ネームサービススイッチ」と呼ばれる別の機能と連係して動作します。ネームサービススイッチは、単に「スイッチ」と呼ばれることもあります。これを使用することにより、Solaris 8 リリースベースのワークステーションは、複数のネームサービスから情報を入手できます。具体的には、ローカルファイル、つまり /etc 内のファイル、NIS マップ、DNS ゾーンファイル、または NIS+ テーブルからです。このスイッチによって、ソースの選択が可能となるだけでなく、ワークステーションは情報の「種類」ごとに別のソースを指定できます。このスイッチの詳細は、第 2 章「ネームサービススイッチ」を参照してください。

Solaris 1.x と NIS 互換モード

Solaris リリース 1.x または 2.x では、NIS+ を NIS が動作しているワークステーションで使用できます。つまり、NIS+ ドメイン内にあるマシンはそれぞれの nsswitch.conf ファイルを nisplus ではなく nis に設定できます。NIS を実行中のマシン上で NIS+ のサービスにアクセスする場合は、NIS+ のサーバーを「NIS 互換モード」で動作させる必要があります。

NIS+ は NIS 互換モードを提供します。NIS 互換モードを使用すれば、Solaris 8 リリースを実行している NIS+ サーバーは、NIS+ クライアントからの要求に応答しながら、NIS クライアントからの要求にも応答できます。NIS+ は 2 つのサービスインタフェースを提供することによってこれを実現します。1 つが NIS+ クライアントの要求に応答し、もう 1 つが NIS クライアントの要求に応答します。

このモードでは、NIS クライアントに対してさらに設定や変更を行う必要はありません。実際、NIS クライアントは、応答しているサーバーが NIS サーバーではないことを意識する必要はありません。ただし、NIS 互換モードで動作している NIS+ サーバーは ypupdate と ypxfr のプロトコルをサポートしないため、複製またはマスターの NIS サーバーとしては使用できません。NIS 互換モードの詳細は、『NIS+ への移行』を参照してください。

さらに 2 つの相違を指摘しておく必要があります。1 つは、NIS 互換モードでサーバーを設定する命令が標準の NIS+ サーバーの設定に使用される命令とは少し異なるということです。詳細は、『Solaris ネーミングの設定と構成』を参照してください。もう 1 つの相違としては、NIS 互換モードは、NIS+ の名前空間内のテーブルに対するセキュリティにも関係があります。NIS のクライアントソフトウェアは、NIS+ サーバーが NIS+ クライアントに与える資格 (credential) を提供する機能がないため、NIS クライアントからの要求はすべて「未認証」として分類されます。したがって、NIS クライアントが NIS+ テーブル内の情報にアクセスできるように、NIS+ の名前空間内のテーブルは未認証の要求に対してアクセス権を提供しなければなりません。これはパート II で説明するように、サーバーを NIS 互換モードで設定するために使用されるユーティリティによって自動的に処理されます。認証プロセスと NIS 互換モードについては、第 6 章「セキュリティの概要」を参照してください。

NIS+ の管理コマンド

NIS+ は、名前空間を管理するためのコマンドをフルセットで提供します。表 3-2 は、これらのコマンドの概要をまとめたものです。

NIS+ の API

NIS+ の API (アプリケーションプログラミングインタフェース) とは、アプリケーションが NIS+ のオブジェクトへのアクセスと修正を行うために呼び出す関数群です。NIS+ の API には、9 つのカテゴリに分類される 54 種類の関数があります。

• オブジェクト操作関数 (nis_names())

• テーブルアクセス関数 (nis_tables())

• ローカル名関数 (nis_local_names())

• グループ操作関数 (nis_groups())

• アプリケーションサブルーチン関数 (nis_subr())

• その他の関数 (nis_misc())

• データベースアクセス関数 (nis_db())

• エラーメッセージ表示関数 (nis_error())

• トランザクションログ関数 (nis_admin())

第 4 章 NIS+ の名前空間

この章では、NIS+ の名前空間の構造、これをサポートするサーバー、およびこれを利用するクライアントについて説明します。

• 「NIS+ ファイルとディレクトリ」

• 「NIS+ 名前空間の構造」

• 「ディレクトリ」

• 「ドメイン」

• 「サーバー」

• 「NIS+ 主体 (クライアント)」

• 「命名規則」

• 「NIS+ の名前展開」

NIS+ ファイルとディレクトリ

表 4-1 は、NIS+ ファイルが格納される UNIX ディレクトリの一覧です。

nisinit など NIS+ 設定プロシージャーによって作成された /var/nis、/var/nis/data といったディレクトリ、およびその下のファイルは、名前を変更しないでください。Solaris 2.4 以前では、/var/nis ディレクトリに hostname.dict、hostname.log という 2 つのファイルが含まれていました。またサブディレクトリ /var/nis/hostname もありました。Solaris 2.5 を起動すると、2 つのファイル名は trans.log、data.dict となり、サブディレクトリ名は /var/nis/data となります。ファイルの「内容」も変更されており、Solaris 2.4 以前との互換性はなくなっています。したがって、これらのファイルやディレクトリを Solaris 2.4 での名前にしてしまうと、Solaris 2.4、2.5 双方の rpc.nisd で機能しなくなりますので名前を変更しないようにしてください。

Solaris オペレーティング環境では、NIS+ データディレクトリ (/var/nis/data.dict) は、マシンに依存しません。そのため、NIS+ 名を簡単に変えることができます。また、NIS+ のバックアップコピーを使用したり機能を復元したりして、NIS+ のデータをひとつのサーバーから別のサーバーに転送もできます。「バックアップと復元を使用して複製サーバーを設定する」を参照してください。

NIS+ 名前空間の構造

NIS+ の名前空間は、NIS+ によって格納された情報を配置したものです。この名前空間は、組織のニーズに合わせていろいろな方法で配置することができます。たとえば、3 つの部門を持つ組織の場合、その NIS+ の名前空間も各部門ごとに 1 つずつで 3 つの部分に分割されます。分割した各部分は、その部門のユーザー、ワークステーション、およびネットワークサービスについての情報を格納しますが、互いに通信することも簡単です。このような配置により、ユーザーによる情報へのアクセスや、管理者による情報の管理が更に容易に行えます。

NIS+ の名前空間の配置はサイトごとに異なりますが、ディレクトリ、テーブル、グループという構成はすべてのサイトが使用します。これらの構成は NIS+「オブジェクト」と呼ばれます。NIS+ オブジェクトは、UNIX のファイルシステムに似た階層形式に配置できます。たとえば、次の図を参照してください。左側の名前空間は、3 つのディレクトリオブジェクト、3 つのグループオブジェクト、および 3 つのテーブルオブジェクトから構成されています。右側の UNIX ファイルシステムは、3 つのディレクトリと 3 つのファイルから構成されています。

NIS+ の名前空間は UNIX ファイルシステムに似ていますが、重要な違いが 5 つあります。

• 両方ともディレクトリを使用するが、NIS+ の名前空間でのオブジェクトはテーブルとグループであり、ファイルではない

• NIS+ の名前空間は、その目的 (システム管理ツール) のために設計された NIS+ の管理コマンド、または Solstice^TM AdminSuite^TM

  ツールなどのグラフィカルユーザーインタフェース (GUI) を通じてだけ管理され、標準の UNIX ファイルシステムコマンドや GUI では管理できない

• UNIX ファイルシステム構成要素の名前はスラッシュで区切られる (/usr/bin) が、NIS+ の名前空間オブジェクト名はドットで区切られる (doc.com.)

• UNIX ファイルシステムの「ルート」へは、ディレクトリを右から左にたどっていけば到達する (/usr/src/file1) が、NIS+ の名前空間のルートは左から右にたどって到達する (sales.doc.com.)

• NIS+ オブジェクト名は、左から右に構成されているので、完全指定名は常にドットで終わる。また最後に「.」がないものは完全な名前とはみなされず、相対的な名前 (まだ上の階層があるという意味) であるとみなされる。

ディレクトリ

ディレクトリオブジェクトは、名前空間の骨格を形成します。ツリー構造に配置した場合、名前空間を別々に分けます。ディレクトリ階層を理解するには、木の根を一番上に置き、逆さまの木として見るとよく分かります。名前空間の一番上のディレクトリが「ルート」ディレクトリです。名前空間が 1 つの層だけの場合、ディレクトリは 1 つしかありませんが、そのディレクトリはルートディレクトリです。ルートディレクトリの下にあるディレクトリオブジェクトは、単に「ディレクトリ」と呼ばれます。

1 つの名前空間は複数の階層のディレクトリを持つことができます。

あるディレクトリと他のディレクトリの関係を考える場合、下側のディレクトリは「子」ディレクトリと呼ばれ、上側のディレクトリは「親」ディレクトリと呼ばれます。

UNIX のディレクトリは UNIX のファイルを入れるように設計されていますが、NIS+ のディレクトリは NIS+ オブジェクト (他のディレクトリ、テーブル、およびグループ) を入れるように設計されています。各 NIS+ のドメインレベルのディレクトリには、以下のサブディレクトリが含まれています。

• groups_dir - NIS+ グループ情報を格納する

• org_dir - NIS+ システムテーブルを格納する

• ctx_dir - FNS を使用しているときだけ使用する

技術的には、ユーザーはディレクトリ、テーブル、およびグループをどんな構造にでも配置することができます。しかし、名前空間内の NIS+ のディレクトリ、テーブル、およびグループは、「ドメイン」と呼ばれる構成に配置されるのが普通です。ドメインは、名前空間の別々の部分をサポートするよう設計されています。たとえば、あるドメインが会社の営業部門 (Sales Division) をサポートし、別のドメインが製造部門 (Manufacturing Division) をサポートできます。

ドメイン

1 つの NIS+ のドメインは、ディレクトリオブジェクト、その org_dir ディレクトリ、その groups_dir ディレクトリ、および NIS+ テーブルのセットから構成されます。

NIS+ のドメインは、実際に存在する名前空間の構成要素ではありません。これらは単に、現実の組織をサポートするために使用される名前空間の「一部分」を示すための便利な方法にすぎません。

たとえば、DOC 社に営業部門と製造部門があるとします。これらの部門をサポートするため、DOC 社の NIS+ 名前空間は、以下に示すような構造によって、3 つの主要ディレクトリグループに配置されることになります。

図 4-1 NIS+ ディレクトリ構造の例

このような構造を、3 つのディレクトリ、6 つのサブディレクトリ、およびいくつかの追加オブジェクトと表現するよりも、3 つのドメインと表現する方が便利です。

図 4-2 NIS+ ドメインの例

サーバー

すべての NIS+ ドメインは複数の NIS+「サーバー」によってサポートされます。サーバーは、ドメインのディレクトリ、グループ、およびテーブルを格納し、ユーザー、管理者、およびアプリケーションからのアクセス要求に応答します。各ドメインは、1 組の複数のサーバーだけによってサポートされます。ただし、この 1 組のサーバーは複数のドメインをサポートできます。

ドメインはオブジェクトではなく、オブジェクトの集合を意味するものであることを忘れないでください。したがって、ドメインをサポートするサーバーは、実際にはドメインにではなく、ドメインのメイン「ディレクトリ」に関連付けられています。

サーバーとディレクトリオブジェクトとのこうした接続は、ドメインを設定するときに行われます。操作説明についてはパート II「NIS+ の紹介と概要」で説明しますが、ここでは大切なことを 1 つ指摘しておきます。それは、この接続が確立されたときに、ディレクトリオブジェクトはそのサーバー名と IP アドレスを格納するということです。後述しますが、クライアントはこの情報を使用してサービス要求を送信します。

Solaris 8 リリースベースのワークステーションは、どれも NIS+ サーバーとなることができます。Solaris 2.4 のリリースには、NIS+ のサーバー用とクライアント用の両方のソフトウェアが入っています。したがって、Solaris 2.x がインストールされているワークステーションであれば、サーバーにもクライアントにも、あるいはその両方にもなることができます。クライアントとサーバーを区別するのは、その果たす役割です。ワークステーションが NIS+ サービスを提供している場合、それは NIS+ サーバーとして機能しています。ワークステーションが NIS+ サービスを要求している場合、これは NIS+ クライアントとして機能しています。

多数のクライアント要求にサービスを提供する必要があるため、NIS+ サーバーとして機能するワークステーションは、平均的なクライアントよりも高いコンピューティング能力と多くのメモリーを装備して構成されます。そして、NIS+ データを格納する必要があるため、より大型のディスクも装備することになります。しかし、性能を高めるためのハードウェアを除いては、サーバーと NIS+ クライアントとの本質的な違いはありません。

NIS+ ドメインをサポートするのは、マスターとその複製の 2 種類のサーバーです。

ルートドメインのマスターサーバーを「ルートマスター」サーバーと呼びます。1 つの名前空間には 1 つのルートマスターサーバーしか存在しません。他のドメインのマスターサーバーは、単にマスターサーバーと呼びます。同様に、ルート複製サーバーと単なる複製サーバーがあります。

マスターサーバーと複製サーバーは、両方とも NIS+ テーブルを格納し、クライアント要求に応答します。ただし、マスターサーバーはドメインのテーブルのマスターコピーを格納し、複製サーバーは複製だけを格納します。管理者は、情報をマスターサーバー内のテーブルにロードし、マスターサーバーはそれを複製サーバーに伝達します。

この配置には 2 つのメリットがあります。第 1 に、マスターテーブルが 1 組しか存在しないことから、テーブル間の不一致を避けることができます。複製サーバーによって格納されたテーブルは、マスターのコピーにすぎません。第 2 に、これによって NIS+ サービスの「信頼性」が大幅に向上します。マスターまたはスレーブのどちらかがダウンした場合、他のサーバーがバックアップとして機能し、サービス要求に応えることができます。

サーバーが変更を伝達する方法

NIS+ のマスターサーバーは、そのオブジェクトをすぐに更新します。しかし、更新内容を複製サーバーに伝達する前に、複数の更新をまとめ (バッチ) ようと試みます。マスターサーバーが、ディレクトリ、グループ、リンク、またはテーブルといったオブジェクトへの更新を受信した場合、約 2 分間ほかの更新が到着しないかどうかを待機して確認します。待機時間が終了すると、これらの更新をディスクと「トランザクションログ」の 2 カ所に格納します (メモリーにはすでに更新を格納)。

マスターサーバーはトランザクションログを使用して、名前空間への変更内容が複製に伝達されるまで、これを格納します。トランザクションログには、更新とタイムスタンプという 2 つの要素が記録されます。

更新とは、変更されたオブジェクトの実際のコピーです。たとえば、ディレクトリが変更された場合、更新はそのディレクトリオブジェクトの完全なコピーです。テーブルエントリが変更された場合、更新は実際のテーブルエントリのコピーです。タイムスタンプは、マスターサーバーによって更新が行われた時間を示します。

その変更内容をトランザクションログに記録したのち、マスターは自分の複製にメッセージを送信し、送信すべき更新があることを知らせます。各複製は、マスターから受信した最後の更新のタイムスタンプでこれに応答します。するとマスターは、各複製のタイムスタンプ以降にログに記録した更新を複製に送信します。

マスターサーバーがその複製サーバーをすべて更新すると、トランザクションログをクリアします。ドメインに新しい複製が追加された場合などには、マスターは、トランザクションログに記録されている最も早い時間のタイムスタンプよりもさらに前のタイムスタンプを複製から受け取ることがあります。この場合、マスターサーバーは全面的な「再同期」、つまり「resync」を行います。resync では、マスターに格納されているすべてのオブジェクトと情報を該当複製にダウンロードします。resync 実行中には、マスターと複製の両方がビジー状態となります。複製は要求に応答できません。マスターは、読み取り要求には応答できますが、更新要求は受け付けできません。両方とも「Server Busy - Try Again」というメッセージで応答します。

NIS+ 主体 (クライアント)

NIS+ 主体とは、NIS+ サービスに要求をするエンティティ (クライアント) のことです。

主体

一般ユーザーであってもスーパーユーザー (root) であってもログインをすれば NIS+ 主体になります。実際の要求は、前者の場合はクライアントユーザーから、後者の場合はクライアントワークステーションから送られます。つまり NIS+ 主体は、クライアントユーザーである場合と、クライアントワークステーションである場合とがあります。

また NIS+ サーバーから NIS+ サービスを提供するエンティティも、NIS+ 主体になることができます。NIS+ サーバーは、すべて NIS+ クライアントと考えることができるので、ここでの説明のほとんどは NIS+ サーバーにも当てはまります。

クライアント

NIS+ クライアントとは、NIS+ サービスを要求するように設定されたワークステーションです。NIS+ クライアントの設定では、セキュリティ資格 (credential) を設定し、クライアントを適切な NIS+ グループのメンバーとし、そのホームドメインを確認し、スイッチ構成ファイルを確認し、最後に NIS+ 初期設定ユーティリティを実行します (詳細は、パート II「NIS+ の紹介と概要」を参照)。

NIS+ クライアントは、セキュリティ上の制約に従って、名前空間のどの部分にもアクセスできます。つまり、認証されており、しかも適切なアクセス権が与えられている場合、名前空間内のどのドメインの情報やオブジェクトにもアクセスできます。

クライアントは名前空間全域にアクセスできますが、1 つのクライアントが所属するドメインは 1 つだけであり、これをその「ホーム」ドメインと呼びます。クライアントのホームドメインは、インストール時に指定されるのが普通ですが、インストール後でも変更または指定できます。クライアントの IP アドレスや資格など、クライアントについてのすべての情報は、そのホームドメインの NIS+ テーブルに格納されています。

NIS+ クライアントであることと、NIS+ テーブルに登録されていることは、微妙な違いがあります。あるワークステーションについての情報を NIS+ テーブルに入力しても、そのワークステーションが自動的に NIS+ クライアントになるわけではありません。これは単に、すべての NIS+ クライアントがそのワークステーションの情報を使用できるようにするだけです。そのワークステーションを実際に NIS+ クライアントとして設定しない限り、NIS+ サービスを要求することはできません。

逆に、あるワークステーションを NIS+ クライアントにしても、そのワークステーションについての情報は NIS+ テーブルに入力されません。これは単に、そのワークステーションで NIS+ サービスを受信できるようにするだけです。管理者がそのワークステーションについての情報を明確に NIS+ テーブルに入力しないと、他の NIS+ クライアントはその情報を入手できません。

クライアントが名前空間へのアクセスを要求した場合、実際には、クライアントは名前空間内の特定ドメインへのアクセスを要求していることになります。したがって、クライアントは、アクセスしようとしているドメインをサポートするサーバーに自分の要求を送信します。簡単に表現すると次のようになります。

クライアントはこのサーバーを、単純な試行錯誤によって認識します。クライアントは、自分のホームサーバーから始めて、正しいサーバーが見つかるまでサーバーを 1 台ずつ試していきます。サーバーがクライアントの要求に応じられない場合、サーバーは適切なサーバーの検索に役立つ情報をクライアントに送信します。やがて、クライアントは自分の情報キャッシュを構築し、適切なサーバーをより効率的に検索できるようになります。このプロセスの詳細を次に示します。

コールドスタートファイルとディレクトリキャッシュ

クライアントが初期設定されるとき、クライアントには「コールドスタートファイル」が与えられます。コールドスタートファイルの目的は、名前空間内のサーバーと連絡をとるための起点として使用できるディレクトリオブジェクトのコピーをクライアントに提供することです。ディレクトリオブジェクトには、アドレス、公開鍵、およびそのディレクトリをサポートするマスターサーバーと複製サーバーについての情報が収められています。通常、コールドスタートファイルには、クライアントのホームドメインのディレクトリオブジェクトが収められています。

コールドスタートファイルは、クライアントの「ディレクトリキャッシュ」を初期設定するためにだけ使用されます。ディレクトリキャッシュは、「キャッシュマネージャ」と呼ばれる NIS+ 機能によって管理され、クライアントが自分の要求を適切なサーバーに送信できるようにするためのディレクトリオブジェクトを格納しています。

名前空間のディレクトリオブジェクトのコピーを自分のディレクトリキャッシュに格納することによって、クライアントは、どのサーバーがどのドメインをサポートするかを知ることができます。クライアントのキャッシュの内容を表示するには、nisshowcache コマンドを使用してください (「nisshowcache コマンド」を参照)。簡単な例を次に示します。

これらのコピーを最新の状態に保つため、各ディレクトリオブジェクトには「生存期間」フィールドがあります。このデフォルト値は 12 時間です。クライアントがディレクトリオブジェクトを求めてディレクトリキャッシュを調べ、最近の 12 時間以内にこれが更新されていないことを発見した場合、キャッシュマネージャはオブジェクトの新しいコピーを獲得します。「nischttl コマンド」で説明するように、ディレクトリオブジェクトの生存期間の値は、nischttl コマンドで変更できます。ただし、生存期間を長くするほどオブジェクトのコピーが古くなる可能性が高くなり、生存期間を短くするほどネットワークトラフィックとサーバーのロードが増加することに注意してください。

ディレクトリキャッシュは、これらのディレクトリオブジェクトをどうやって蓄積するのでしょうか。前に説明したように、コールドスタートファイルはキャッシュ内の最初のエントリを提供します。したがって、クライアントが最初の要求を送信するとき、コールドスタートファイルによって指定されたサーバーに要求を送信します。その要求がそのサーバーによってサポートされるドメインへのアクセスである場合、そのサーバーは要求に応答します。

その要求が別のドメイン (たとえば、sales.doc.com.) へのアクセスである場合、サーバーは、クライアントが適切なサーバーを探すのを助けようとします。サーバーが、自分のディレクトリキャッシュ内に該当するドメイン用のエントリを保有している場合、そのドメインのディレクトリオブジェクトのコピーをクライアントに送信します。クライアントは、その情報を今後の参照用として自分のディレクトリキャッシュにロードし、そのサーバーに要求を送信します。

ほとんどありえないことですが、クライアントがアクセスしようとしているディレクトリオブジェクトのコピーを、サーバーが保有していない場合、そのサーバーは、自分のホームドメインのディレクトリオブジェクトのコピーをクライアントに送信します。ここには、そのサーバーの親のアドレスが登録されています。クライアントは、親サーバーを使ってこのプロセスを繰り返し、適切なサーバーを見つけるか、または名前空間内の全サーバーを試し終わるまで、これを繰り返します。クライアントがドメイン内の全サーバーを試し終わった後でどうするかは、そのネームサービススイッチ構成ファイルの指示によって決まります。詳細は、第 2 章「ネームサービススイッチ」を参照してください。

やがてクライアントは、名前空間内のすべてのディレクトリオブジェクトのコピーをキャッシュ内に蓄積します。したがって、これらディレクトリオブジェクトをサポートするサーバーの IP アドレスも蓄積することになります。クライアントが他のドメインへのアクセス要求を送信する必要があるとき、通常は、自分のディレクトリキャッシュの中から自分のサーバー名を見つけ、そのサーバーにアクセス要求を直接送信できます。

NIS+ サーバーはクライアントでもある

NIS+ サーバーは NIS+ クライアントでもあります。実際、ワークステーションをサーバーとして設定する (パート II「NIS+ の紹介と概要」を参照) には、その前にクライアントとして初期設定しなければなりません。唯一の例外はルートマスターサーバーであり、このサーバーには独自の設定を行う必要があります。

つまり、サーバーはドメインをサポートするだけではなく、ドメインにも「所属する」のです。つまり、クライアントになることによって、サーバーにはホームドメインがあるということです。サーバーのホスト情報は自分のホームドメインの hosts テーブルに格納され、その DES 資格は自分のホームドメインの cred テーブルに格納されます。他のクライアントと同様、サーバーは、自分のディレクトリキャッシュに記録されているサーバーに対して、サービス要求を送信します。

忘れてはならない重要な点は、ルートドメインを除いて、サーバーのホームドメインは、そのサーバーがサポートするドメインの「親」ドメインであるということです。

つまり、サーバーは 1 つのドメイン内のクライアントをサポートしますが、別のドメインの「クライアント」になるのです。ルートドメインを除いて、サーバーは自分のサポートするドメインのクライアントにはなれません。ルートドメインをサポートするサーバーには親ドメインがないため、これらはルートドメイン自体に所属します。

たとえば、次のような名前空間を考えてみます。

各サーバーがどのドメインをサポートし、どのドメインに所属するかを次に示します。

命名規則

NIS+ の名前空間内のオブジェクトは、「部分指定」と「完全指定名」という 2 種類の名前によって識別できます。部分指定名は「単純」名とも呼ばれ、単なるオブジェクトの名前か、または完全指定名の一部分です。ある管理業務を行なっている間にユーザーがオブジェクトまたは主体の部分指定名を入力した場合、NIS+ はその名前を完全指定名に展開しようと試みます。詳細は、「NIS+ の名前展開」を参照してください。

完全指定名とは、名前空間内でオブジェクトを探すために必要なすべての情報を含んだオブジェクトの完全な名前です。必要なすべての情報とはオブジェクトの親ディレクトリ (もしあれば)、最後のドットも含んだ完全なドメイン名などです。

これはオブジェクトの種類によって異なるため、各タイプと NIS+ の主体ごとの規則を別個に説明します。次の名前空間を例として使用します。

NIS+ の主体を含めて、この名前空間内の全オブジェクトの完全指定名を図 4-3 に要約します。

図 4-3 名前空間の構成要素の完全指定名

NIS+ ドメイン名

完全指定ドメイン名は左から右に作成され、ローカルドメインで始まってルートドメインで終わります。たとえば次のようになります。

doc.com. (ルートドメイン)

sales.doc.com. (サブドメイン)

intl.sales.doc.com. (サブドメイン)

最初の行はルートドメインの名前を示します。ルートドメインは、少なくとも 2 つのラベルを持ち、ドットで終わらなければなりません。最後 (右端) のラベルは自由につけられますが、インターネット上の互換性を維持するためには、表 4-2 に示されるようなインターネットの組織名、または 2、3 文字の地域識別子 (日本であれば .jp) をつける必要があります。

上の 2 行目と 3 行目は下位レベルドメインの名前です。

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

ディレクトリの単純名は、単にディレクトリオブジェクトの名前です。この完全指定名は、単純名にそのドメインの完全指定名を加えたものです (常に最後のドットを含む)。

groups_dir (単純名)

groups_dir.manf.doc.com. (完全指定名)

複数のディレクトリ層が 1 つのドメインを形成しないような変則的な階層を設定する場合、中間ディレクトリ名を含めるようにしてください。たとえば、次のようにします。

lowest_dir.lower_dir.low_dir.mydomain.com.

通常単純名は、同じドメイン内から使用され、完全指定名は、リモートドメインから使用されます。しかし、ドメインの NIS_PATH 環境変数に検索パスを指定することによって、リモートドメインから単純名を使用できます (「NIS+ の名前展開」を参照してください)。

テーブルおよびグループ名

完全指定されたテーブル名とグループ名は、オブジェクト名から始まり、ディレクトリ名をつけ、その後に完全指定されたドメイン名が続いて作られます。すべてのシステムテーブルオブジェクトは org_dir ディレクトリに格納されて、すべてのグループオブジェクトは groups_dir ディレクトリに格納されていることを忘れないでください。独自の NIS+ テーブルを作成した場合は、どこでも好きなところに格納できます。グループ名とテーブル名の例を次に示します。

admin.groups_dir.doc.com.
admin.groups_dir.doc.com.
admin.groups_dir.sales.doc.com.
admin.groups_dir.sales.doc.com.
hosts.org_dir.doc.com.
hosts.org_dir.doc.com.
hosts.org_dir.sales.doc.com.
hosts.org_dir.sales.doc.com.

テーブルエントリ名

NIS+ テーブル内のエントリを識別するには、その中にあるエントリとテーブルオブジェクトを識別する必要があります。このような名前を「インデックス付き」名と呼びます。この構文を次に示します。

[column=value,column=value,...],tablename 

Column はテーブル列の名前です。Value はその列の実際の値です。tablename はテーブルオブジェクトの完全指定名です。hosts テーブルのエントリ例を次に示します。

[addr=129.44.2.1,name=pine],hosts.org_dir.sales.doc.com.
[addr=129.44.2.2,name=elm],hosts.org_dir.sales.doc.com.
[addr=129.44.2.3,name=oak],hosts.org_dir.sales.doc.com.

括弧の中には、テーブルエントリを一意に識別するために必要な最小限の列の値のペアを使用できます。

一部の NIS+ 管理コマンドは、この構文のバリエーションを利用できます。詳細は、パート II「NIS+ の紹介と概要」の nistbladm、nismatch、nisgrep の各コマンドの説明を参照してください。

ホスト名

ホスト名の長さは 24 文字までで、使用できるのは文字、数字、ダッシュ (-)、および下線 (_) です。大文字と小文字の区別はありません。また先頭は英文字とします。スペースは使用できません。

ドット (.) を含むホスト名 (myco.2 など) は使用できません。これは、`myco.2' のように引用符を使用しても同じです。ドットを使用するのは、完全指定のホスト名の一部として表記するときだけです (myco-2.sales.doc.com など)。

またドメイン名とホスト名が同じにならないようにします。たとえば、sales ドメインがある場合は、ホスト名に sales を使用することはできません。同様に、home というホスト名がある場合には、ドメイン名に home を使用できません。これは、サブドメインについても同様です。たとえば、すでにホスト名として west がある場合には、sales.west.myco.com というサブドメインを作ることはできません。

NIS+ 主体の名前

NIS+ の主体名は、Secure RPC のネット名とよく混同することがあります。これらの名前については、パート II「NIS+ の紹介と概要」のセキュリティに関する章で説明します。念のためここで 1 つだけ違いを指摘しておきます。NIS+ の主体名は必ずドットで終わりますが、Secure RPC のネット名はドットで終わることは絶対ありません。

また、たとえ主体の資格が cred テーブルに格納されていても、cred テーブル名も org_dir ディレクトリ名も主体名には含まれません。

使用できる記号

名前空間名は、ISO ラテン 1 セットの印刷可能文字を自由に使用して作成できます。ただし、名前の先頭には次に示す文字は使用できません。@ < > + [ ] - / = . , : ;

文字列を使用するには、二重引用符で囲みます。名前の中に引用符を使用するには、その記号も引用符で囲みます (たとえば、o'henry を使用するには o"'"henry と入力します)。John Smith などのように空白スペースを組み込むには、次のように一重引用符の中で二重引用符を使用します。

`"John Smith"`

ホスト名に適用される制限については 「ホスト名」を参照してください。

NIS+ の名前展開

NIS+ のコマンドで完全指定名を入力することは面倒です。この作業を簡単にするため、NIS+ は名前展開機能を提供します。部分指定名が入力されると、NIS+ は別のディレクトリのもとでこのオブジェクトを見つけようと試みます。最初は、デフォルトドメインから探します。これは、このコマンドを入力したクライアントのホームドメインです。デフォルトドメインでオブジェクトが見つからなかった場合、このオブジェクトが見つかるまで、NIS+ はデフォルトドメインの親ディレクトリを下から上へ探していきます。2 つのラベルしかない名前に到達すると、検索を停止します。次にその例を示します。この例では、software.big.sales.doc.com. ドメインに所属するクライアントにログインしたと仮定します。

環境変数 NIS_PATH

環境変数 NIS_PATH の値を変更することによって、NIS+ が検索するディレクトリのリストを変更または拡張できます。NIS_PATH には、コロンで区切って複数のディレクトリ名を設定できます。次に例を示します。

setenv NIS_PATH directory1:    directory2: directory3 ...

または

NIS_PATH=directory1:    directory2: directory3 ...;export NIS_PATH

NIS+ は、これらのディレクトリを左から右へ検索していきます。たとえば、次のようになります。

$PATH や $MANPATH のように、変数 NIS_PATH には特殊記号 $ を使用できます。$ 記号は、ディレクトリ名に追加するか、または単独で追加できます。ディレクトリ名に追加した場合、NIS+ はその名前にデフォルトディレクトリを追加します。たとえば、次のようになります。

$ 記号を単独で使用する (たとえば、org_dir.$:$) 場合、NIS+ は前述のような標準の名前展開を実行します。つまり、デフォルトディレクトリの検索から始め、親ディレクトリへと進めていきます。NIS_PATH のデフォルト値は $ です。

NIS_PATH に追加や変更を加えると、NIS+ がより多くの検索を行わなければならないので、性能が低下するという点に注意してください。

第 5 章 NIS+ のテーブルと情報

この章では、これらのテーブルの構造と設定方法の概要について説明します。

• 「NIS+ テーブルの構造」

• 「テーブルの設定方法」

NIS+ テーブルの構造

NIS+ は、さまざまなネットワーク情報をテーブルに格納します。NIS+ テーブルには、単純なテキストファイルやマップには見られない機能がいくつかあります。これらのテーブルは列エントリ構造をもち、検索パスを使用することや、リンクすることができ、しかも複数の設定方法があります。NIS+ にはあらかじめ構成された 16 個のシステムテーブルがあり、独自のテーブルを作成することもできます。表 5-1 は、事前構成した NIS+ テーブルを示します。

cred テーブルには NIS+ のセキュリティに関係する情報だけが入っています。これについては第 7 章「NIS+ 資格の管理」で説明します。

これらのテーブルには、ユーザー名からインターネットサービスまでの幅広い情報が格納されています。この情報の多くは、設定時または構成の手順の中で生成されます。たとえば、password テーブル内のエントリは、ユーザーアカウントが設定されたときに作成されます。hosts テーブル内のエントリは、ワークステーションがネットワークに加えられたときに作成されます。また、networks テーブル内のエントリは、新しいネットワークが設定されたときに作成されます。

この情報はこのような広範囲にわたる操作によって生成されるため、このマニュアルでは詳細を説明していません。ただし、テーブルの各列に含まれる情報については付録 C 「NIS+ テーブルの情報」 で要約し、NIS+ のグループとネットグループとを区別する場合など、混乱を避けるために必要な場合にだけ詳細を示します。テーブルの情報の詳細は、Solaris の「システム管理マニュアルセット」と「ネットワーク管理マニュアルセット」を参照してください。

ドメインにさらに多くのオートマウントマップを作成できますが、必ず NIS+ テーブルとして格納し、auto_master テーブルの中に入れてください。オートマウントマップを作成して、ユーザー用に作成された auto_master に追加するときは、列名にはキーと値が必要です。オートマウントの詳細は、オートマウントまたは NFS ファイルシステムの関連マニュアルを参照してください。

ネームサービスとして、NIS+ テーブルはオブジェクト自体ではなく、オブジェクトの参照情報を格納するように設計されています。そのため、NIS+ はエントリの大きなテーブルをサポートできません。テーブルに非常に大きなエントリがある場合、rpc.nisd は機能しません。

列とエントリ

NIS+ テーブルにはさまざまな種類の情報が格納されていますが、これらの基本構造はすべて同じで、行と列から構成されます。行は「エントリ」または「エントリオブジェクト」と呼ばれます。

クライアントは、キーだけではなく、任意の検索可能な列によっても情報にアクセスできます。たとえば、baseball という名前のワークステーションのネットワークアドレスを見つけるには、ホスト名の列を探して baseball を見つけます。

次に、baseball のエントリ行を移動して、そのネットワークアドレスを見つけます。

クライアントは、任意のレベルでテーブル情報にアクセスできる (つまり、テーブルに全体としてアクセスできる) ため、NIS+ は 3 つのレベルすべてにセキュリティ機構を提供しています。たとえば、管理者は、オブジェクトレベルで全員にテーブルの読み取り権を割り当て、列レベルで所有者に変更権を割り当て、エントリレベルでグループに変更権を割り当てることができます。テーブルのセキュリティの詳細は、第 10 章「NIS+ のアクセス権の管理」で説明しています。

検索パス

テーブルには、その「ローカル」ドメインについての情報だけが収められています。たとえば、doc.com. ドメイン内のテーブルには、doc.com. ドメインのユーザー、クライアント、およびサービスについての情報だけが収められています。sales.doc.com. ドメイン内のテーブルには、sales.doc.com. ドメインのユーザー、クライアント、およびサービスについての情報だけが収められています。

あるドメイン内のクライアントが、別のドメインに格納されている情報を見つけようとした場合、完全指定名を使用しなければなりません。「NIS+ の名前展開」で説明したように、環境変数 NIS_PATH が正しく設定されていれば、NIS+ サービスがこれを自動的に処理します。

情報を探すときにサーバーがたどる「検索パス」をどの NIS+ テーブルでも指定できます。この検索パスは、NIS+ テーブルをコロンで区切って順番に並べたものです。

table:table:table...

検索パス内のテーブル名は、完全指定をする必要はありません。テーブル名は、コマンド行で入力された名前と同じように展開されます。サーバーが自分のローカルテーブル内に情報を検出できなかった場合、サーバーはクライアントにテーブルの検索パスを返します。クライアントはそのパスを使用して、その情報が見つかるかまたは最後まで、検索パスに名前があるすべてのテーブルを順番に探していきます。

検索パスのメリットを次に示します。次のようなドメイン階層があるとします。

下位にある 3 つのドメインの hosts テーブルの内容は次のようになります。

ここで、sales.doc.com. ドメイン内の luna にログインしたユーザーが、別のクライアントにリモートログインする場合を考えてみます。このユーザーが完全指定名を指定しない場合、そのユーザーがリモートログインできるのは localhost、phoebus、europa、ganymede、および mailhost の 5 台のワークステーションだけです。

sales.doc.com. ドメインにある hosts テーブルの検索パスが、次のように、manf.doc.com. ドメインの hosts テーブルを指定していると仮定します。

hosts.org_dir.manf.doc.com.

これで sales.doc.com. ドメイン内のユーザーは、たとえば、rlogin sirius と入力することができ、NIS+ サーバーはこれを検出します。NIS+ サーバーはまずローカルドメインで sirius を探し、見つからなければ manf.doc.com. ドメイン内を探します。クライアントは manf.doc.com. ドメインをどのように認識するのでしょうか。第 4 章「NIS+ の名前空間」で説明したように、この情報はディレクトリキャッシュに格納されています。これがディレクトリキャッシュにない場合、クライアントは、第 4 章「NIS+ の名前空間」で説明したプロセスに従ってこの情報を入手します。

ただし、検索パスを指定する方法には、若干の欠点があります。ユーザーがたとえば、rlogin luba (luna でなく) などと間違った名前を入力した場合、サーバーは 1 つのテーブルではなく、3 つのテーブルを探さなければエラーメッセージを返せません。名前空間の全域に検索パスを設定した場合、1 つの操作は 2、3 のドメインではなく、10 個のドメイン内のテーブルを検索してから終了します。もう 1 つの欠点は、多数のクライアントが NIS+ テーブルにアクセスする必要があるとき、複数のサーバーのセットと通信するために、性能低下を招くという点です。

また、mailhost は別名として使用されることが多いため、特定のメールホストについての情報を探したいときは、その完全指定名 (mailhost.sales.doc.com. など ) を使用しなければなりません。そうしないと、NIS+ は検索したすべてのドメインで見つけたすべてのメールホストを返します。

テーブルの検索パスを指定するには、「nistbladm コマンド」で説明するように、nistbladm コマンドに -p オプションを付けて実行します。

テーブルの設定方法

NIS+ テーブルの設定には 3 つまたは 4 つの作業が伴います。

1. org_dir ディレクトリの作成

2. システムテーブルの作成

3. システムテーブル以外のテーブルの作成 (必要に応じて)

4. 情報を入力してテーブルを生成 (populate) する

第 4 章「NIS+ の名前空間」で説明したように、NIS+ のシステムテーブルは org_dir ディレクトリに格納されます。したがって、テーブルを作成するには、その前にテーブルを入れる org_dir ディレクトリを作成しなければなりません。これには 3 つの方法があります。

• nisserver スクリプトを使用。nisserver スクリプトは、ディレクトリとシステムテーブのルフルセットを作成します。nisserver スクリプトを実行することを推奨します。

• nismkdir コマンドを使用。nismkdir コマンドは単にディレクトリを作成するものです。

• /usr/lib/nis/nissetup ユーティリティを使用。nissetup ユーティリティは org_dir および groups_dir ディレクトリとシステムテーブルのフルセットを作成します。

nisserver スクリプト、nissetup および nismkdir ユーティリティについては、『Solaris ネーミングの設定と構成』に説明があります。nismkdir コマンドに関するその他の情報については、「nismkdir コマンド」に説明があります。

nissetup ユーティリティのメリットは、サーバーが NIS 互換モードで動作しているドメインのテーブルに対して、適切なアクセス権を割り当てる機能です。-Y フラグを付けて実行すると、このユーティリティは作成するオブジェクトの「未認証」カテゴリに読み取りアクセス権を割り当てます。その結果、未認証の NIS クライアントは、そのドメインの NIS+ テーブルから情報を得ることができます。

NIS+ の 16 個のシステムテーブルと、これらに格納される情報の種類については、付録 C 「NIS+ テーブルの情報」 で説明しています。これらを作成するには、前述の 3 つの方法を使用できます。nistbladm コマンドは NIS+ テーブルの作成と変更を行います。nistbladm コマンドで名前空間内のすべてのテーブルを作成できますが、入力量が多くなり、列の正確な名前やアクセス権を知っている必要があります。nisserver スクリプトを使う方が、はるかに簡単です。

システムテーブル以外のテーブル、つまり NIS+ によってまだ構成されていないテーブルを作成するには、nistbladm コマンドを使用します。オートマウントマップを追加する場合は、キーの列と値の列が必要です。

NIS+ テーブルを生成するには、NIS マップから行う方法、ASCII ファイル (/etc 内のファイルなど) から行う方法、および手作業の 3 つの方法があります。

NIS サービスからアップグレードしている場合、すでにネットワーク情報の大部分が NIS マップに格納されています。この情報を NIS+ テーブルに手作業で再入力する必要はありません。nispopulate スクリプトか nisaddent ユーティリティで自動的に転送できます。

他のネットワーク情報サービスを使用していない場合で、しかもネットワークデータを /etc 内のファイルで管理しているときも、この情報を再入力する必要はありません。nispopulate スクリプトか nisaddent ユーティリティを使用すれば自動的に転送できます。

ネットワークを初めて設定する場合、多くのネットワーク情報をすでにどこかに格納しているということはおそらくないでしょう。この場合、まず情報を入手して、次に NIS+ テーブルに手作業で入力する必要があります。これを行うには、nistbladm コマンドを使用できます。また、特定のテーブルの全情報を「入力ファイル」(これは本質的に /etc 内のファイルと同じです) に入力し、次に、nispopulate スクリプトか nisaddent ユーティリティを使用してファイルの内容を転送することによっても同じことが行えます。

テーブルの更新方法

ドメインが設定されると、サーバーはそのドメインの NIS+ テーブルの最初のバージョンを受け取ります。これらのバージョンはディスクに格納されますが、サーバーは起動されると、これらをメモリーにロードします。サーバーがテーブルに対する更新を受信すると、サーバーはそのメモリーにあるテーブルをすぐに更新します。サーバーが情報の要求を受信すると、その応答のためにメモリーにあるコピーを使用します。

もちろん、サーバーはその更新をディスクにも格納する必要があります。ディスクにあるテーブルを更新するには時間がかかるため、NIS+ の全サーバーはテーブル用の「ログ」ファイルを持っています。このログファイルは、テーブルに対して行われた変更内容を、ディスク上で更新できるまで、一時的に格納するように設計されています。ログファイルは、テーブル名を接頭辞として使用し、これに .log を追加します。たとえば、次のようになります。

hosts.org_dir.log
bootparams.org_dir.log
password.org_dir.log
ipnodes.org_dir.log

ログファイルが大きくなりすぎて大量のディスク領域を占有しないように、ディスクにあるテーブルのコピーは毎日更新しなければなりません。このプロセスは「チェックポイントを実行する」と呼ばれます。これには、nisping -C コマンドを使用します。

第 6 章 セキュリティの概要

この章では、NIS+ のセキュリティシステムと、システムが NIS+ 名前空間全体に与える影響について説明します。

• 「Solaris のセキュリティ - 概要」

• 「NIS+ のセキュリティ - 概要」

• 「NIS+ の認証と資格 - 紹介」

• 「NIS+ の承認とアクセス - 紹介」

• 「NIS+ 管理者」

• 「NIS+ のパスワード、資格、およびコマンド」

Solaris のセキュリティ - 概要

Solaris のセキュリティは、ユーザーが Solaris 環境に入るために通過しなければならないゲートと、内部でそのユーザーが何をできるのかを判定するアクセス権マトリックスの 2 つによって確保されています。(図 6-1 参照)

図 6-1 Solaris のセキュリティゲートとフィルタ

図 6-1 に示すように、4 つのゲートと 2 つのアクセス権マトリックスによってシステム全体が構成されています。

• 「ダイアルアップゲート」

  モデムや電話回線により Solaris 環境にアクセスするには、正しいログイン ID とダイアルアップパスワードが必要です。

• 「ログインゲート」

  Solaris 環境に入るには、正しいログイン ID とユーザーパスワードが必要です。

• 「ファイルおよびディレクトリマトリックス」

  Solaris 環境に入ってから、ファイルやディレクトリに関して、読み取り、実行、変更、作成、削除等の各種操作を行う権限はアクセス権マトリックスによってコントロールされます。

• 「root ゲート」

  root 権限にアクセスするには、正しいスーパユーザー (root) パスワードが必要です。

• 「RPC ゲートによる保護」

  セキュリティレベル 2 (デフォルト値) の NIS+ 環境においては、NIS+ サービスを使って NIS+ オブジェクト (サーバー、ディレクトリ、テーブル、テーブルエントリなど) にアクセスしようとする場合、ユーザー ID は SECURE RPC プロセスを使った NIS+ によって確認されます。

  ダイヤルアップ、ログイン、ルートゲート、およびファイルとディレクトリのアクセス権マトリクスの詳細は、Solaris の各マニュアル及び資料を参照してください。

  SECURE RPC ゲートをパスするには、SECURE RPC パスワードが必要です。「SECURE RPC パスワード」は、「ネットワークパスワード」と呼ばれる場合もあります。SECURE RPC パスワードとログインパスワードは通常同一なので、ゲートをパスした場合はパスワードを再入力する必要がありません (2 つのパスワードが異なった場合についての説明は、「Secure RPC パスワードとログインパスワードの問題」 を参照)。

  ユーザー要求が SECURE RPC ゲートをパスするには、1 組の「資格」セットが使われます。ユーザーの資格を、作成、提示、判定するプロセスを、そのプロセスがユーザーが誰であり、正しい RPC パスワードを所持しているか否かを確認することから、「認証 (authentication)」と呼びます。この認証プロセスは、ユーザーが NIS+ サービスを要求するごとに自動的に実行されます。

  NIS 互換モード (YP 互換モードでもある) の NIS+ 環境では、ユーザーが正しい資格を所持しているか否かにかかわらず (認証プロセスによって、ID が確認され、SECURE RPC パスワードがチェックされたか否かにかかわらず)、誰でもすべての NIS+ オブジェクトを読み取ることができ、またそれらエントリを変更できるので、SECURE RPC ゲートによるガードは極めて弱くなります。誰もがすべての NIS+ オブジェクトを読み取りかつそれらエントリを変更できるので、互換モードの NIS+ ネットワークは通常モードのよりも安全性が低くなります。

  NIS+ の認証と資格の作成および管理については、第 7 章「NIS+ 資格の管理」を参照してください。

• 「NIS+ オブジェクトマトリックス」

  一度正しく認証されると、ユーザーが NIS+ オブジェクトを読み取り、変更、作成、削除する権限はアクセス権マトリックスに管理されます。このプロセスをNIS+ の「承認 (authorization)」と呼びます。

  NIS+ のアクセス権および承認の詳細は、第 10 章「NIS+ のアクセス権の管理」を参照してください。

NIS+ のセキュリティ - 概要

NIS+ のセキュリティは NIS+ の名前空間全体にかかわっています。セキュリティと名前空間を別に設定することはできません。このため、セキュリティの設定方法は名前空間の各構成要素を設定する手順と密接に関係することになります。一度 NIS+ のセキュリティ環境を設定すると、その後はユーザーの追加および削除、アクセス権の変更、グループメンバーの再割当やネットワーク展開を管理するために必要なその他すべての管理ルーチンタスクを実行できます。

NIS+ のセキュリティ機能は名前空間内の情報と、名前空間そのものの構造を不正アクセスから保護するものです。このセキュリティ機能がなければ、どんな NIS+ クライアントであっても名前空間に保存された情報を獲得することも変更することもできないだけでなく、ダメージを与える可能性があります。

NIS+ セキュリティには次の 2 つの機能があります。

• 「認証 (authentication)」

  認証は NIS+ 主体を識別するのに使われます。主体 (ユーザーまたはマシン) が NIS+ オブジェクトにアクセスしようとするときはいつも、ユーザー ID と SECURE RPC パスワードが確認されチェックされます。

• 「承認 (authorization)」

  承認はアクセス権を識別するのに使われます。NIS+ 主体が NIS+ オブジェクトにアクセスしようとするときはいつも、所有者、グループ、その他、未認証の 4 つのクラスの 1 つに位置付けられています。NIS+ セキュリティシステムは NIS+ 管理機能により、各クラスに NIS+ オブジェクトに対する読み取り、変更、作成、削除の各権限を指定します。たとえば、あるクラスは passwd テーブルの特定列を変更できるが、その列を読み取ることはできないとか、別のクラスはいくつかのエントリを読み取ることはできるが、それ以外はできないというように設定できます。

NIS+ のセキュリティ機能は 2 段階のプロセスを用意しています。

1. 「認証 (authentication)」

   NIS+ は資格 (credential) を使ってユーザーを確認します。

2. 「承認 (authorization)」

   承認プロセスがユーザー ID を確認すると、NIS+ はクラスを判定します。NIS+ オブジェクトまたはサービスに対して何が行えるのかは、ユーザーがどのクラスに属しているかに依存します。これは UNIX の標準的なファイルおよびディレクトリのアクセス権システムと同様の考え方に基づいています (クラスの詳細は、「承認クラス」を参照)。

このプロセスは、マシン A のルート権限により su コマンドを使って、第 2 の NIS+ アクセス権で NIS+ オブジェクトにアクセスすることを防ぐものです。

しかしながら NIS+ は、他人のユーザーログインパスワードを知っている者が、そのユーザーになりすましてユーザー ID と NIS+ アクセス権を使用することを妨げることはできません。またルート権限を持つユーザーが同一マシンからログインしている別のユーザーになりすますのを防ぐこともできません。

図 6-2 に、このプロセスの詳細を示します。

図 6-2 NIS+ セキュリティプロセスの概要

NIS+ の主体について

NIS+ の主体とは、NIS+ サービス要求を依頼するエンティティ (クライアント) です。NIS 主体には、クライアントマシンに一般ユーザーとしてログインしたユーザー、スーパーユーザーとしてログインしたユーザー、NIS+ クライアントマシンにおいてスーパーユーザー特権で動作しているプロセスを含みます。つまり NIS+ の主体はクライアントユーザーの場合もクライアントワークステーションの場合もあります。

NIS+ の主体は、NIS+ サーバーから NIS+ サービスを提供する主体を指すこともあります。すべての NIS+ サーバーは NIS+ クライアントにもなるので、サーバーが NIS+ の主体となる場合もあります。

NIS+ のセキュリティレベルについて

NIS+ サーバーは 2 つのセキュリティレベルの 1 つで動作できます。これらのレベルが、主体がその要求の認証を受ける際に提示しなければならない資格種類を判定します。NIS+ は最も高度のセキュリティレベル (レベル 2) で動作するように設計されています。レベル 0 はテスト、設定、デバッグ用です。セキュリティレベルについては表 6-1 にまとめてあります。

セキュリティレベルとパスワードコマンド

Solaris リリース 2.0 から 2.4 の環境では、nispasswd を使用してパスワードを変更します。ただし、資格がなければ、nispasswd は機能しません (より上位のレベルでの資格があった場合を除き、セキュリティレベル 0 以下では機能しない)。Solaris リリース 2.5 以降の場合は、セキュリティレベルや資格ステータスにかかわらず、passwd コマンドを使ってパスワードを変更できます。

NIS+ の認証と資格 - 紹介

NIS+ 資格の目的は、NIS+ サービスや NIS+ オブジェクトへのアクセスを要求する各主体の ID を「認証」(確認) することにあります。つまり、NIS+ 資格および承認プロセスは SECURE RPC システムを実装することです。

資格および認証システムは他人になりすますのを防ぐシステムです。あるマシンのルート権限を持つユーザーが su コマンドを使って、ログインしていないもしくは別のマシンにログインしている第 2 のユーザーになりすまし、NIS+ アクセス権を使用して NIS+ オブジェクトにアクセスすることを妨げます。

サーバーが主体を認証すると、主体は 4 つの認証クラスのどれかに置かれ、次にサーバーは承認されている動作を知るためにアクセスしようとする NIS+ オブジェクトをチェックします。承認の詳細は、「NIS+ の承認とアクセス - 紹介」を参照してください。

ユーザーおよびマシンの資格

主体には、「ユーザー」と「マシン」の 2 つの基本的な種類があります。

• 「ユーザー (user) 資格」。レギュラーユーザーとして NIS+ クライアントにログインした場合、NIS+ サービス要求には当人の「ユーザー」資格を含みます。

• 「マシン (machine) 資格」。スーパーユーザーとして NIS+ クライアントにログインした場合、サービス要求は「クライアントワークステーション」資格を使います。

DES と LOCAL 資格

NIS+ 主体には DES と LOCAL の 2 つの資格が用意されています。

DES 資格 (credential)

認証を行う仕組みとしては DES 資格が唯一のものです。将来は他の仕組みも利用できるようになるかもしれません。DES 資格と NIS+ 資格は同等のものではありません。

このマニュアルでは、DES 資格という用語は、鍵の長さにかかわりなく Diffie - Hellman 鍵をベースにした認証を表すものとして一搬的に使われています。鍵の長さはあらかじめ決められたセットから指定することができます。Diffie - Hellman 鍵の長さの設定や表示を行うには nisauthconf(1M) を使用します。

DES (データ暗号化規格) 資格は資格の 1 種であり、保護認証を提供するものです。このマニュアルで NIS+ 主体を認証するために資格をチェックすると記述している場合は、NIS+ がチェックしている DES 資格のことを意味します。

主体が NIS+ サービスを要求したり、NIS+ オブジェクトにアクセスするごとに、ソフトウェアは格納してある資格情報を使って主体の資格を作成します。DES 資格は NIS+ 管理機能によって各主体に作られた情報から作成されます。第 7 章「NIS+ 資格の管理」を参照してください。

• 主体の DES 資格の正当性を NIS+ が確認すると、その主体は「認証」されます。

• 主体は所有者、グループ、その他のいずれかの承認クラスを得るために認証されなければなりません。つまり、これらクラスの１つを得るために、有効な DES 資格を持つ必要があるのです。有効な DES 資格を持たない主体は自動的に未認証クラスに割り当てられます。

• 当該主体がクライアントユーザーであるかクライアントワークステーションであるかにかかわらず、DES 資格情報は常に主体のホームドメインの cred テーブルに格納されます。

LOCAL 資格

LOCAL 資格は、ユーザー ID 番号とホームドメイン名を含む NIS+ 主体名とのマップです。ユーザーがログインすると、システムは DES 資格が格納されているホームドメインを特定する LOCAL 資格をチェックします。システムはその情報を使ってユーザーの DES 資格情報を獲得します。

ユーザーがリモートドメインにログインした場合、その要求はユーザーのホームドメインを示す LOCAL 資格を使います。NIS+ は次にユーザーの DES 資格情報を知るためにユーザーのホームドメインを問い合わせます。こうして、たとえユーザーの DES 資格情報がリモートドメインに格納されていなくても、リモートドメインで認証されます。

図 6-3 資格とドメイン

LOCAL 資格情報はどのドメインにも格納できます。実際、リモートドメインにログインし認証されるためには、クライアントユーザーはリモートドメインの cred テーブルに LOCAL 資格を持っている必要があります。ユーザーが、アクセスしようとするリモートドメインに LOCAL 資格を持っていなかった場合、NIS+ はユーザーの DES 資格を獲得するためにユーザーのホームドメインに入ることができなくなります。そのような場合、ユーザーは認証されず未認証クラスを与えられることになります。

ユーザー種類と資格種類

ユーザーは両方の資格を持つことができますが、マシンは DES 資格しか持てません。

すべてのマシンのルート UID は常に 0 であるため、ルートは他のマシンに対して NIS+ アクセスできません。もしマシン A のルート (UID=0) がマシン B にアクセスしようとすると、すでに存在しているマシン B のルート (UID=0) と衝突します。これでは、クライアント「ワークステーション」の LOCAL 資格が意味をなさないのでクライアント「ユーザー」にだけ認められています。

NIS+ の承認とアクセス - 紹介

NIS+ の承認の基本的目的は、各 NIS+ 主体が各 NIS+ オブジェクトとサービスに対して持っているアクセス権を特定することにあります。

一度主体の NIS+ 要求が認証されると、NIS+ は承認クラスを与えます。NIS+ オブジェクトに対して行うことのできる動作を指定するアクセス権は各クラスに与えられます。クラスごとに別のアクセス権が与えられる場合、各承認クラスはそれぞれアクセス権を持つということです。

• 「承認クラス」には次の 4 つがあります。所有者、グループ、その他、未認証 (詳細は、次の「承認クラス」を参照)。

• 「アクセス権」には次の 4 つがあります。作成 (CREATE)、削除 (DESTROY)、変更 (MODIFY)、読み取り (READ) (詳細は、「NIS+ のアクセス権について」を参照)。

承認クラス

NIS+ オブジェクトは NIS+ 主体に直接アクセス権を与えずに、主体の 4 つの「クラス」にアクセス権を与えます。

• 「所有者」

  オブジェクトの所有者になった主体が所有者クラスの権限を与えられます。

• 「グループ」

  各 NIS+ オブジェクトグループは関連した 1 つのグループを持ちます。オブジェクトグループのメンバーは NIS+ 管理機能が指定します。オブジェクトグループクラスに属している主体がグループクラスの権限を与えられます。この場合の「グループ」とは NIS+ グルーブを表します。UNIX のグループやネットグループのことではありません。

• 「その他」

  その他クラスは、サーバーが認証できるすべての NIS+ 主体を包含するクラスです。所有者とグループクラスを除く、すべての認証されたものを意味します。

• 「未認証」

  認証されていないものすべてを意味します。

図 6-4 承認クラス

NIS+ 要求のすべてについて、システムは要求主体が属しているクラスと、そのクラスが所持しているアクセス権を判定します。

オブジェクトに対するアクセス権は、各クラスで任意の組み合わせが可能です。しかしながら、通常は上位クラスが下位クラスのすべての権限に追加権限を持つように割り当てられます。

たとえば、未認証クラスとその他クラスに読み取り権が与えられていれば、読み取り権と変更権の両方をグループクラスに、そして読み取り権、変更権、作成権、および削除権を所有者クラスに与えます。

4 つのクラスについては、以下に詳述します。

所有者クラス

所有者は 1 つの NIS+ 主体です。

NIS+ オブジェクトへのアクセスを要求する主体は、所有者アクセス権を得る前に認証され (有効な DES 資格を提示し) なければなりません。

デフォルトでは、オブジェクト所有者はオブジェクトを作成できる主体です。しかしながら、オブジェクト所有者は 2 つの方法で別の主体に所有権を譲ることができます。

• オブジェクトが作成されたときに、主体が別の所有者を指定する方法 ( 「コマンドによるアクセス権の指定」を参照)

• オブジェクトの作成後に、主体がオブジェクトの所有権を変更する方法 ( 「オブジェクトとエントリの所有権の変更」を参照)

一度主体が所有権を放棄すると、その主体はオブジェクトに対する所有者のアクセス権すべてを放棄することになり、グループ、その他、未認証のいずれかの所有権を持つことになります。

グループクラス

オブジェクトグループは 1 つの NIS+ グループです。この場合の「グループ」とは、UNIX のグループやネットグループのことではありません。

NIS+ オブジェクトにアクセスを要求する主体は、認証され (有効な DES 資格を提示し) かつグループアクセス権を与えられる前にそのグループに属していなければなりません。

1 つの NIS+ グループは NIS+ 主体の集合であり、名前空間へのアクセス権を与えるのに都合の良いようにまとめられたものです。NIS+ グループに与えられるアクセス権はそのグループのメンバーである主体すべてに適用されます。オブジェクトの所有者が、そのオブジェクトのグループに属している必要はありません。

オブジェクトが作成された時、そのオブジェクトはデフォルトグループに割り当てられます。オブジェクトが作成された時でもその後でも、そのオブジェクトをデフォルト以外のグループに割り当てることができます。オブジェクトグループはいつでも変更できます。

NIS+ グループに関する情報は NIS+ group テーブルに格納されるのではないことに注意してください。NIS+ group テーブルには UNIX グループに関する情報が格納されます。NIS+ グループに関する情報は、適切な groups_dir ディレクトリのオブジェクトに格納されます。

NIS+ グループの情報は、各 NIS+ ドメインの groups_dir サブディレクトリにある、NIS+ グループ「オブジェクト」に格納されます。

図 6-5 NIS+のディレクトリ構造

NIS+ グループの管理については、第 12 章「NIS+ グループの管理」を参照してください。

その他クラス

その他クラスは、NIS+ によって認証されたすべての NIS+ 主体のクラスです。すなわち、所有者およびグループクラスのすべてと有効な DES 資格を提示したものを加えたものです。

その他に与えられたアクセス権は、認証されたすべての主体に適用されます。

未認証クラス

未認証クラスは、正しく認証されなかったものすべてで構成されます。すなわち、有効な DES 資格を提示しなかったものです。

承認クラスと NIS+ オブジェクトの階層

NIS+ オブジェクトと承認クラスには各レベルに適用される階層があります。標準的な NIS+ ディレクトリ階層のデフォルトは次のようになります。

• 「ディレクトリレベル」

  各 NIS+ ドメインには groups_dir と org_dir という 2 つの NIS+ ディレクトリオブジェクトがあります。groups_dir ディレクトリオブジェクトはさまざまなグループで構成されます。各 org_dir ディレクトリオブジェクトには種々のテーブルが含まれます。

• 「グループレベルまたはテーブルレベル」

  グループは個々のエントリやグループで構成されます。テーブルには列 と個々のエントリが含まれます。

• 「列レベル」

  テーブルは 1 つ以上の列で構成されます。

• 「エントリ (行) レベル」

  グループもしくはテーブルは 1 つ以上のエントリを持ちます。

各レベルには 4 つの承認クラスが適用されます。ディレクトリオブジェクトはそれ自身の所有者とグループを持ちます。ディレクトリ内の個々のテーブルは、ディレクトリの所有者およびグループと異なる所有者およびグループを持ちます。テーブル内では、1 エントリ (行) が個々の所有者もしくはグループを持ちます。この所有者もしくはグループは、テーブル全体の所有者やグループとは異なり、またオブジェクト全体の所有者やグループとも異なります。テーブル内の個々の列は、テーブル全体と同じ所有者やグループを持ちます。

NIS+ のアクセス権について

NIS+ オブジェクトはオブジェクト定義の一部としてそのアクセス権を指定します。「NIS+ オブジェクトのアクセス権の読み取り」に niscat -o コマンドを使用した場合の説明があります。

NIS+ オブジェクトは、UNIX ファイルが UNIX ユーザーに対するアクセス権を指定するのと同じ方法で、NIS+ 主体に対するアクセス権を指定します。アクセス権は、NIS+ 主体が NIS+ オブジェクトについて実行することが許されている動作の種類を表します。

NIS+ の動作はオブジェクトの種類によって異なりますが、読み取り、変更、作成、および削除の 4 つのクラスに分類されます。

• 「読み取り」

  オブジェクトの読み取り権を持った主体はオブジェクトの内容を読み取ることができます。

• 「変更」

  オブジェクトの変更権を持った主体はオブジェクトの内容を変更することができます

• 「削除」

  オブジェクトの削除権を持った主体はオブジェクトの内容を削除することができます。

• 「作成」

  上位レベルのオブジェクトの作成権を持った主体はそのレベル内で新しいオブジェクトを作成できます。すなわち、NIS+ ディレクトリオブジェクトの作成権を持っていれば、そのディレクトリ内に新しいテーブルを作成できます。NIS+ テーブルの作成権を持っていれば、そのテーブル内に新しい列とエントリを作成できます。

NIS+ クライアントから NIS+ サーバーへのすべての通信は、実際には特定の NIS+ オブジェクトに対してこれらの動作のうちの 1 つを実行してほしいという要求です。たとえば、NIS+ 主体が他のワークステーションの IP アドレスを要求した場合、これは実際には、この種の情報を格納している「hosts」テーブルオブジェクトへの読み取り権を要求しています。主体が NIS+ 名前空間にディレクトリを追加するようサーバーに要求した場合、これは実際には、そのディレクトリの親オブジェクトに対して変更権を要求しています。

これらの権限は、ディレクトリからテーブルへ、さらにテーブルの列およびエントリへと展開することを覚えておいてください。たとえば、新しいテーブルを作成するには、テーブルを格納するディレクトリオブジェクトに対して作成権を持っていなければなりません。テーブルを作成する場合は、ユーザーはそのテーブルのデフォルト所有者になります。所有者として、テーブルに新しいエントリを作成できる作成権を自分自身に割り当てることができます。テーブルに新しいエントリを作成する場合は、ユーザーはそのエントリのデフォルト所有者になります。所有者として、他のユーザーにテーブルレベルの作成権を与えることもできます。たとえば、テーブルのグループクラスにテーブルレベルの作成権を与えることができます。その場合、そのテーブルグループのすべてのメンバーがテーブルに新しいエントリを作成できます。新規のテーブルエントリを作成する個々のグループメンバーはそのエントリのデフォルト所有者になります。

NIS+ 管理者

NIS+ オブジェクトの「管理権限」を持つものは誰でも NIS+ の管理者になります。説明を分かりやすくするために、管理権限が作成権、削除権、そしていくつかのオブジェクトに対しては変更権を持つと定義します。NIS+ のアクセス権については、「NIS+ のアクセス権について」を参照してください。

NIS+ オブジェクトを作成するものは誰でもそのオブジェクトに対する初期アクセス権を持つと設定します。もし作成者が管理権限をオブジェクトの所有者に限った場合 (初期状態では作成者) は、所有者だけがそのオブジェクトに対する管理権限を持ちます。一方、作成者が管理権限をオブジェクトのグループに与えた場合は、グループの全員がそのオブジェクトに対して管理権限を持つことになります。

あるオブジェクトに対して管理権限を持つものは誰でもそのオブジェクトの NIS+ 管理者とみなされます。

すなわち、NIS+ ソフトウェアは NIS+ 管理者を 1 人にしようとするものではないということです。

理論的には、管理権限をその他クラスに与えることも、未認証クラスに与えることもでき、ソフトウェア上では可能です。しかし、管理権限をグループクラス以上に広げて与えてしまうと、NIS+ のセキュリティを実質的に無効にしてしまいます。もし管理権限をその他クラスや未認証クラスに与えた場合、NIS+ のセキュリティは保証されません。

NIS+ のパスワード、資格、およびコマンド

管理者のパスワード、資格、および鍵には次のコマンドを使用します。各コマンドの説明についてはマニュアルを参照してください。

• chkey - 主体の Secure RPC 鍵の組み合わせを変更します。必要のない場合は chkey を使わずに、passwd を使ってください。詳細は、「NIS+ 主体の鍵の変更」 を参照してください。

• keylogin - keyserv を使って主体の非公開鍵を復号化し格納します。

• keylogout - keyserv から非公開鍵を削除します。

• keyserv - サーバーに非公開暗号鍵を格納させます。詳細は、「キーログイン」を参照してください。

• newkey - 公開鍵データベースに新規の鍵の組み合わせを作成します。

• nisaddcred - NIS+ 主体に資格 (credential) を作成します。詳細は、「資格情報の作成」および、「NIS+ 資格情報の管理」を参照してください。

• nisauthconf - Diffie - Hellman 鍵の長さの表示あるいは設定を行います。

• nisupdkeys - ディレクトリオブジェクト内の公開鍵を更新します。詳細は、「公開鍵の更新」を参照してください。

• passwd - 主体のパスワードを変更し管理します。詳細は、第 11 章「パスワードの管理」を参照してください。