| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
Oracle Solaris 11.1 でのネットワークファイルシステムの管理 Oracle Solaris 11.1 Information Library (日本語) |
| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
|
Oracle Solaris 11.1 でのネットワークファイルシステムの管理 Oracle Solaris 11.1 Information Library (日本語) |
3. ネットワークファイルシステムへのアクセス (リファレンス)
Oracle Solaris 11 リリースで NFS version 4 のデフォルトドメインを構成する
Solaris 10 リリースで NFS version 4 のデフォルトドメインを構成する
NFS version 4 におけるファイルシステムの共有解除と再共有
NFS version 4 におけるファイルシステムの名前空間
NFS version 4 における OPEN 共有サポート
NFS version 4 での ACL と nfsmapid
ACL エントリ内のすべてのユーザーおよびグループ ID が NFS version 4 のクライアントとサーバーの両方に存在することを確認します。
マウント時の -public オプションと NFS URL の意味
NFS version 4 におけるクライアント側フェイルオーバー機能
autofs のナビゲーションプロセス開始法 (マスターマップ)
autofs がクライアント用のもっとも近い読み取り専用ファイルを選択する方法 (複数ロケーション)
次のセクションでは、NFS の複雑な機能をいくつか紹介します。このセクションで紹介する機能のいくつかは、NFS version 4 専用であることに注意してください。
注 - システムでゾーンが有効なときに非大域ゾーンでこの機能を使用する場合は、詳細について『Oracle Solaris 11.1 の管理: Oracle Solaris ゾーン、Oracle Solaris 10 ゾーン、およびリソース管理』を参照してください。
NFS 起動プロセスには、サーバーとクライアントのプロトコルレベルのネゴシエーションが含まれています。バージョンのレベルを指定しない場合、デフォルトにより最適なレベルが選択されます。たとえば、クライアントとサーバーの両方が version 3 をサポートしていると、version 3 が使用されます。クライアントまたはサーバーが version 2 しかサポートしていないと、version 2 が使用されます。
sharectl コマンドを使用して、client_versmin、client_versmax、server_versmin、および server_versmax パラメータを設定できます。これらのキーワードのデフォルト値に代わって、クライアントとサーバーに最小値と最大値を指定できます。クライアントとサーバーの最小値は 2 がデフォルトで、最大値は 4 がデフォルトです。サーバーによってサポートされるバージョンを検出するために、NFS クライアントは client_versmax の設定から始めて、client_versmin のバージョン設定に到るまで各バージョンを試行し続けます。サポートされるバージョンが検出されるとすぐに、この処理は終了します。たとえば、client_versmax=4 および client_versmin =2 の場合、クライアントは最初に version 4、次に version 3、最後に version 2 を試行します。client_versmax と client_versmax が同じ値に設定されていると、クライアントは常にこのバージョンを使用し、その他のバージョンは試行しません。サーバーがこのバージョンをサポートしていない場合、マウントは失敗します。
手順については、「NFS サービスの設定」を参照してください。
version 4 の NFS は大幅に変更が行われました。このセクションでは、これらの新しい機能を説明します。
注 - Solaris 10 以降のリリースでは、NFS version 4 は LIPKEY/SPKM セキュリティー方式をサポートしません。また、mountd、nfslogd、および statd デーモンを使用しません。
NFS version 4 の使用に関する手順については、「NFS サービスの設定」を参照してください。
NFS version 3 と version 4 では、クライアントが共有を解除されたファイルシステムにアクセスしようとすると、サーバーはエラーコードを返します。ただし、NFS version 3 では、ファイルシステムが共有されなくなる前に、サーバーはクライアントが取得したロックを保持します。したがって、ファイルシステムが再度共有されるとき、NFS version 3 クライアントは、そのファイルシステムが共有解除されなかったかのように、ファイルシステムにアクセスできます。
NFS version 4 では、ファイルシステムの共有を解除するとき、そのファイルシステムにあるオープンファイルまたはファイルロックの状態がすべて削除されます。クライアントは、これらのファイルにアクセスしようとしたりロックしようとしたりすると、エラーを受け取ります。通常、このエラーは、アプリケーションに対する入出力エラーとして報告されます。ただし、オプションを変更するために現在共有されているファイルシステムを再共有しても、サーバーの状態は削除されません。
関連情報については、「NFS version 4 におけるクライアント回復」を参照するか、unshare_nfs(1M) のマニュアルページを参照してください。
NFS version 4 サーバーは、擬似ファイルシステムを作成し管理します。擬似ファイルシステムにより、クライアントは、サーバー上のエクスポートされた全ファイルにシームレスにアクセスできます。NFS version 4 より前のバージョンには、擬似ファイルシステムがありません。クライアントは、アクセスする各共有サーバーのファイルシステムに強制的にマウントされます。次のような例を考えます。
図 3-2 サーバーのファイルシステムとクライアントのファイルシステムの表示
クライアントには payroll ディレクトリと nfs4x ディレクトリは表示されません。これらのディレクトリはエクスポートされておらず、エクスポートされたディレクトリには通じていないためです。ただし、local ディレクトリは、エクスポートされたディレクトリであるため、クライアントに表示されます。projects ディレクトリは、エクスポートされたディレクトリ nfs4 に通じているため、クライアントに表示されます。このように、明示的にエクスポートされていないサーバーの名前空間の部分は、擬似ファイルシステムで橋渡しされます。この擬似ファイルシステムは、エクスポートされたディレクトリ、およびサーバーのエクスポートに通じるディレクトリだけを表示します。
擬似ファイルシステムは、ディレクトリだけを含む構造で、サーバーによって作成されます。擬似ファイルシステムにより、クライアントはエクスポートされたファイルシステムの階層を検索できるようになります。このようにして、クライアントの擬似ファイルシステムの表示は、エクスポートされたファイルシステムに通じるパスに限定されます。
以前のバージョンの NFS では、クライアントは、サーバーのファイルシステムを検索するには、各ファイルシステムをマウントする必要がありました。しかし、NFS version 4 では、サーバーの名前空間が次のことを行います。
クライアントのファイルシステム表示を、サーバーのエクスポートに通じるディレクトリに限定します。
クライアントが配下の各ファイルシステムをマウントしなくても、サーバーのエクスポートにシームレスにアクセスできるようにします。前述の例を参照してください。オペレーティングシステムが異なるとき、クライアントはサーバーの各ファイルシステムをマウントする必要のある場合があります。
ファイルハンドルは、サーバー上で作成され、ファイルとディレクトリを一意に識別する情報を持ちます。NFS version 2 と version 3 では、サーバーは持続的ファイルハンドルを返しました。したがって、クライアントは、サーバーが常に同じファイルを参照するファイルハンドルを生成することを保証できました。例:
ファイルが削除され同じ名前のファイルに置き換えられた場合、サーバーは必ず新しいファイルの新しいファイルハンドルを生成する。クライアントが古いファイルハンドルを使用していた場合、サーバーはファイルハンドルが無効であることを示すエラーを返す。
ファイル名が変更されている場合、ファイルハンドルは変更されない。
サーバーをリブートする必要があった場合、ファイルハンドルは変更されない。
このように、サーバーがファイルハンドルを含むクライアントからの要求を受け取った場合、解決策は単純であり、ファイルハンドルは常に正しいファイルを参照します。
NFS を操作するためのファイルとディレクトリを識別するこの方法は、多くの UNIX ベースのサーバーに適しています。ただし、この方法は、ファイルのパス名などほかの識別方法を使用するサーバー上では実装できません。この問題を解決するために、NFS version 4 プロトコルは、サーバーがそのファイルハンドルが揮発性であることを宣言できるようにします。したがって、ファイルハンドルが変更されます。ファイルハンドルが変更された場合、クライアントは新しいファイルハンドルを検出する必要があります。
NFS version 2 と 3 のように、Oracle Solaris NFS version 4 サーバーは常に持続的ファイルハンドルを提供します。ただし、Solaris NFS version 4 以外のサーバーにアクセスする Oracle Solaris NFS version 4 クライアントは、そのサーバーが揮発性ファイルハンドルを使用する場合、揮発性ファイルハンドルをサポートする必要があります。特に、サーバーがクライアントにファイルハンドルが揮発性であることを知らせている場合は、クライアントはパス名とファイルハンドル間のマッピングをキャッシュする必要があります。クライアントは、期限切れになるまで、揮発性ファイルハンドルを使用します。期限が切れたとき、クライアントは次を実行します。
そのファイルハンドルを参照するキャッシュされた情報をフラッシュする
そのファイルの新しいファイルハンドルを検索する
操作をもう一度実行する
注 - サーバーは、どのファイルハンドルが持続的あるいは揮発性かを、クライアントに常に知らせます。
揮発性ファイルハンドルは、次のいずれかの理由により期限切れになります。
ファイルを閉じたとき
ファイルハンドルのファイルシステムが移行するとき
クライアントがファイル名を変更するとき
サーバーがリブートするとき
クライアントが新しいファイルハンドルを検索できない場合、エラーメッセージが syslog ファイルに追加されます。このファイルにアクセスしようとすると、入出力エラーで失敗します。
NFS version 4 プロトコルは、ステートフルプロトコルです。クライアントとサーバーが次の項目に関する現在の情報を管理するとき、プロトコルはステートフルです。
オープンファイル
ファイルロック
サーバーのクラッシュなどの障害が発生したとき、クライアントとサーバーは連携して、障害が発生する前のオープン状態とロック状態を再度確立します。
サーバーがクラッシュしてリブートしたとき、サーバーの状態は消失します。クライアントは、サーバーがリブートしたことを検出して、サーバーの状態の再構築を支援するプロセスを開始します。このプロセスは、クライアントがプロセスを指示するため、クライアント回復として知られています。
クライアントは、サーバーがリブートしたことを検出すると、ただちに現在の動作を停止して、クライアント回復のプロセスを開始します。回復プロセスが開始されたとき、次のようなメッセージが、システムエラーログ/var/adm/messages に表示されます。
NOTICE: Starting recovery server basil.example.company.com
回復プロセスの間、クライアントは、クライアントの以前の状態に関するサーバー情報を送信します。ただし、この間、クライアントはサーバーに新しい要求を送信しません。ファイルのオープンやファイルロックの設定の新しい要求は、サーバーが回復を完了するのを待ってから続行する必要があります。
クライアント回復プロセスが完了したとき、次のメッセージがシステムエラーログ /var/adm/messages に表示されます。
NOTICE: Recovery done for server basil.example.company.com
クライアントは、サーバーへの状態情報の送信を正常に完了しました。ただし、クライアントがこのプロセスを完了しても、その他のクライアントがサーバーに状態情報を送信するプロセスを完了していない可能性があります。したがって、しばらくの間、サーバーはオープンまたはロック要求を受け付けません。この期間は猶予期間として知られており、すべてのクライアントが回復を完了できるように指定されています。
猶予期間中に、クライアントが新しいファイルを開こうとしたり、新しいロックを確立しようとしたりすると、サーバーは GRACE エラーコードで要求を拒否します。このエラーを受け取ったとき、クライアントは猶予期間が終わるのを待ってから、要求をサーバーに再送信します。猶予期間中は、次のメッセージが表示されます。
NFS server recovering
猶予期間中、ファイルを開いたりファイルロックを設定したりしないコマンドは処理できることに注意してください。たとえば、コマンド ls と cd はファイルを開いたりファイルロックを設定したりしません。したがって、これらのコマンドは中断されません。ただし、ファイルを開く cat などのコマンドは、猶予期間が終わるまで中断されます。
猶予期間が終了すると、次のメッセージが表示されます。
NFS server recovery ok.
クライアントは、サーバーに新しいオープン要求またはロック要求を送信できるようになります。
クライアント回復は、さまざまな理由により失敗することがあります。たとえば、サーバーのリブート後にネットワークパーティションが存在する場合、クライアントは、猶予期間が終了する前にサーバーとの状態を再度確立できません。猶予期間が終了すると、新しい状態操作により競合が発生するため、サーバーはクライアントに状態の再確立を許可しません。たとえば、新しいファイルロックは、クライアントが回復しようとしている古いファイルロックと競合します。このような状況が発生すると、サーバーは NO_GRACE エラーコードをクライアントに返します。
特定のファイルに対するオープン操作の回復が失敗すると、クライアントはファイルを使用不可能としてマークし、次のメッセージが表示されます。
WARNING: The following NFS file could not be recovered and was marked dead (can't reopen: NFS status 70): file : filename
番号 70 は 1 つの例です。
回復中にファイルロックの再確立が失敗した場合、次のエラーメッセージが送信されます。
NOTICE: nfs4_send_siglost: pid PROCESS-ID lost lock on server SERVER-NAME
この場合、SIGLOST シグナルがプロセスに送信されます。SIGLOST シグナルのデフォルトの動作は、プロセスを中断することです。
この状態から回復するには、障害発生時にファイルを開いていたすべてのアプリケーションを再起動する必要があります。次のことに注意してください。
ファイルを再度開くことができない一部のプロセスは入出力エラーを受け取ります。
ファイルを再度開いたり、または回復の失敗後にオープン操作を実行したその他のプロセスは、問題なくファイルにアクセスできます。
このように、特定のファイルにアクセスできるプロセスとアクセスできないプロセスがあります。
NFS version 4 プロトコルには、クライアントがほかのクライアントによるファイルアクセスの制御に使用するファイル共有モードがいくつかあります。クライアントは、次のように指定できます。
DENY_NONE モードを指定すると、ほかのクライアントはファイルへの読み取りと書き込みアクセスを許可されます。
DENY_READ モードを指定すると、ほかのクライアントはファイルへの読み取りアクセスを拒否されます。
DENY_WRITE モードを指定すると、ほかのクライアントはファイルへの書き込みアクセスを拒否されます。
DENY_BOTH モードを指定すると、ほかのクライアントはファイルへの読み取りと書き込みアクセスを拒否されます。
Oracle Solaris NFS version 4 サーバーは、これらのファイル共有モードを完全に実装します。したがって、クライアントが現在の共有モードと矛盾する方法でファイルを開こうとすると、サーバーは操作を失敗させて、その試行を拒否します。このような試行が、ファイルのオープン操作または作成操作の開始に失敗すると、 NFS version 4 クライアントはプロトコルエラーを受け取ります。このエラーは、アプリケーションエラー EACCES にマップされます。
プロトコルにはいくつかの共有モードがありますが、現在のところ、Oracle Solaris でのオープン操作では、複数の共有モードを提供していません。ファイルを開くとき、Oracle Solaris NFS version 4 クライアントは、DENY_NONE モードだけを使用します。
また、fcntl システムコールには、ファイルの共有を制御する F_SHARE コマンドがありますが、fcntl コマンドは NFS version 4 では正しく実装できません。NFS version 4 クライアントで fcntl コマンドを使用すると、クライアントはアプリケーションに EAGAIN エラーを返します。
NFS version 4 は、委託のクライアントサポートとサーバーサポートを提供します。委託とは、サーバーがファイルの管理をクライアントに委託するテクニックです。たとえば、サーバーは、読み取り委託または書き込み委託のいずれかをクライアントに付与できます。読み込み委託は互いに競合しないため、複数のクライアントに同時に付与できます。書き込み委託はほかのクライアントのファイルアクセスと競合するため、1 つのクライアントにだけ付与できます。書き込み委託を保持している間、クライアントは、ファイルへの排他的アクセスを保証されているために、さまざまな操作をサーバーに送信しません。同様に、読み込み委託を保持している間、クライアントはさまざまな操作をサーバーに送信しません。クライアントが書き込みモードでファイルを開けないことをサーバーが保証するためです。委託により、委託されたファイルに対するサーバーとクライアントの相互作用を大幅に減少することができます。したがって、ネットワークトラフィックが減少し、クライアントとサーバーのパフォーマンスが向上します。ただし、パフォーマンス向上の度合いは、アプリケーションが使用するファイルの相互作用の種類およびネットワークとサーバー輻輳の量によって異なります。
委託を付与するかどうかの決定は、サーバーがすべて行います。クライアントは、委託を要求しません。サーバーは、ファイルに対するアクセスパターンに基づいて、委託を付与するかどうかを決定します。複数の異なるクライアントから書き込みモードで、ファイルが最近アクセスされた場合、サーバーは委託を付与しないことがあります。このアクセスパターンは将来競合する可能性があることを示しているためです。
競合は、ファイルに付与されている委託と一致しない方法でクライアントがそのファイルにアクセスするときに発生します。たとえば、あるクライアントがファイルの書き込み委託を保持しており、2 番目のクライアントが読み取りまたは書き込みアクセス用にそのファイルを開くとサーバーは最初のクライアントの書き込み委託を再呼び出しします。同様に、あるクライアントが読み取り委託を保持しており、別のクライアントが書き込み用に同じファイルを開くと、サーバーは読み取り委託を再呼び出しします。どちらの場合も、競合が存在しているため、2 番目のクライアントは委託を付与されません。競合が発生すると、サーバーはコールバックメカニズムを使用して、委託を保持しているクライアントと連絡をとります。このコールバックを受信すると、クライアントはファイルの更新された状態をサーバーに送信し、委託を返します。クライアントが再呼び出しに対する応答に失敗すると、サーバーは委託を取り消します。こうした場合、サーバーはこのファイルに対するクライアントの操作をすべて拒否し、クライアントは要求された操作を失敗として報告します。一般的に、これらの失敗は入出力エラーとしてアプリケーションに報告されます。これらのエラーから回復するには、ファイルを閉じてから再度開く必要があります。取り消された委託による失敗は、クライアントが委託を保持している間にクライアントとサーバー間にネットワークパーティションが存在しているときに発生します。
サーバーは、別のサーバーに格納されているファイルに対するアクセスの競合を解決できません。つまり、NFS サーバーは、格納しているファイルに対する競合だけを解決します。さらに、さまざまなバージョンの NFS を実行しているクライアントによって発生する競合に対して、NFS サーバーは NFS version 4 を実行しているクライアントにだけ再呼び出しを開始します。以前のバージョンの NFS を実行しているクライアントに再呼び出しを開始できません。
競合を検出するプロセスはさまざまです。たとえば、NFS version 4 とは異なり、version 2 と version 3 にはオープン手順がないため、クライアントがファイルの読み取り、書き込み、またはロックを試行したあとでのみ、競合が検出されます。これらの競合に対するサーバーの応答もさまざまです。例:
NFS version 3 では、サーバーは JUKEBOX エラーを返します。これにより、クライアントはアクセス要求を停止し、あとで再試行します。クライアントは、File unavailable というメッセージを出力します。
NFS version 2 では、JUKEBOX エラーと同等のエラーが存在しないため、サーバーは応答しません。これにより、クライアントは待機してから再試行します。クライアントは、NFS server not responding というメッセージを出力します。
これらの状態は、委託の競合が解決されたときにクリアされます。
デフォルトでは、サーバー委託は有効になっています。server_delegation パラメータを none に設定すると、委託を無効にできます。手順については、「サーバー上で異なるバージョンの NFS を選択する方法」を参照してください。
クライアントの委託にキーワードは必要ありません。NFS version 4 コールバックデーモン nfs4cbd により、クライアント上のコールバックサービスが提供されます。このデーモンは、NFS version 4 のマウントが有効になると自動的に起動されます。デフォルトで、クライアントは、/etc/netconfig システムファイルに一覧表示されているすべてのインターネット転送に必要なコールバック情報を提供します。クライアントで IPv6 が有効であり、クライアントの名前の IPv6 アドレスが指定されている場合、コールバックデーモンは IPv6 接続を受け入れます。
コールバックデーモンは、一時的なプログラム番号と動的に割り当てられたポート番号を使用します。この情報は、サーバーに提供され、サーバーは委託を付与する前にコールバックパスをテストします。コールバックパスが正常にテストされない場合、サーバーは委託を付与しません。外部から見ることのできる動作だけになります。
コールバック情報は NFS version 4 要求に組み込まれているため、サーバーは、NAT (Network Address Translation) を使用するデバイスを通してクライアントと連絡を取ることができません。また、コールバックデーモンは、動的ポート番号も使用します。したがって、ファイアウォールがポート 2049 上で通常の NFS トラフィックを有効にしている場合でも、サーバーがファイアウォールを検索できない場合があります。この場合、サーバーは委託を付与しません。
アクセス制御リスト (ACL) は、ファイルの所有者が、ファイル所有者、グループ、そのほかの固有のユーザーおよびグループに関するファイルアクセス権を定義できるようにすることで、ファイルのセキュリティーを高めます。ZFS ファイルシステムでは、ACL は、chmod コマンドを使用することで、サーバーおよびクライアント上で設定されます。UFS ファイルシステムの場合は、setfacl コマンドを使用します。詳細は、chmod(1) および setfacl(1) のマニュアルページを参照してください。NFS version 4 では、ID マッパー nfsmapid を使用して、サーバー上の ACL エントリ内のユーザーまたはグループ ID を、クライアント上の ACL エントリ内のユーザーまたはグループ ID にマッピングします。逆も同じです。ACL エントリのユーザーおよびグループ ID は、クライアントとサーバーの両方に存在する必要があります。
次の状態は、ID マッピングが失敗する原因になる可能性があります。
サーバー上の ACL エントリ内に存在するユーザーまたはグループをクライアント上の有効なユーザーまたはグループにマッピングできない場合、ユーザーは ACL を読み取ることはできますが、ユーザーやグループの一部が「不明」と表示されます。
たとえば、ls -lv や ls -lV コマンドを発行した場合、一部の ACL エントリでグループやユーザーが「不明」と表示されます。このコマンドの詳細は、ls(1) のマニュアルページを参照してください。
クライアント上で設定されている ACL エントリ内のユーザーまたはグループ ID をサーバー上の有効なユーザーまたはグループ ID にマッピングできない場合、setfacl や chmod コマンドが失敗し、 Permission denied エラーメッセージを返す可能性があります。
クライアントとサーバーで nfsmapid_domain の値が一致しない場合、ID マッピングは失敗します。詳細は、「nfsmapid デーモン」を参照してください。
ID マッピングの問題を回避するには、次の処置を行います。
nfsmapid_domain の値が正しく設定されていることを確認します。
ACL エントリ内のすべてのユーザーおよびグループ ID が NFS version 4 のクライアントとサーバーの両方に存在することを確認します。
サーバーまたはクライアント上でユーザーまたはグループをマッピングできるかどうかを判別するには、次のスクリプトを使用します。
#! /usr/sbin/dtrace -Fs
sdt:::nfs4-acl-nobody
{
printf("validate_idmapping: (%s) in the ACL could not be mapped!",
stringof(arg0));
}
注 - このスクリプトで使用されているプローブ名は、将来変更される可能性があるインタフェースです。詳細については、『Solaris Dynamic Tracing Guide』の「Stability Levels」を参照してください。
次を参照してください。
開始時には、トランスポートプロトコルもネゴシエートされます。デフォルトでは、クライアントとサーバーの両方がサポートしているコネクション型トランスポートの中で最初に見つかったものが選択されます。それが見つからない場合は、コネクションレス型トランスポートプロトコルの中で最初に見つかったものが使用されます。システムでサポートされているトランスポートプロトコルのリストは、/etc/netconfig にあります。TCP はコネクション型トランスポートプロトコルで、Solaris 2.6 からサポートされています。UDP はコネクションレス型トランスポートプロトコルです。
NFS プロトコルのバージョンとトランスポートプロトコルが両方ともネゴシエーションによって決まった場合は、NFS プロトコルのバージョンがトランスポートプロトコルよりも優先されます。UDP を使用する NFS version 3 プロトコルの方が、TCP を使用する NFS version 2 プロトコルよりも優先されます。mount コマンドでは NFS プロトコルのバージョンもトランスポートプロトコルも手動で選択できます。mount_nfs(1M) のマニュアルページを参照してください。ほとんどの場合、ネゴシエーションによって選択されるオプションの方が適切です。
ファイル転送サイズは、クライアントとサーバーの間でデータを転送するときに使用されるバッファーのサイズです。原則として、ファイル転送サイズが大きいほどパフォーマンスが向上します。NFS version 3 には転送サイズに上限はありませんが、クライアントは、必要であればマウント時にこれより小さい転送サイズを提示することができますが、ほとんどの場合その必要はありません。
転送サイズは、NFS version 2 を使用しているシステムとはネゴシエートされません。このとき、ファイル転送サイズの上限は 8K バイトに設定されます。
mount コマンドに対して -rsize オプションと -wsize オプションを使用すると、転送サイズを手動で設定できます。PC クライアントの一部では転送サイズを小さくする必要があります。また、NFS サーバーが大きなファイル転送サイズに構成されている場合は、転送サイズを大きくすることができます。
注 - Solaris 10 以降のリリースでは、書き込み転送サイズの制限が緩和されました。使用するトランスポートプロトコルに基づいて転送サイズが決定されるようになりました。たとえば、UDP 使用時の NFS 転送の上限は、以前と同じく 32K バイトです。これに対し、TCP は UDP のようなデータグラム制限を持たないストリーミングプロトコルであるため、TCP 使用時の最大転送サイズは、1M バイトまで拡張されています。
次の説明は、NFS version 3 のマウントに適用されます。NFS version 4 のマウントプロセスは、ポートマップサービスおよび MOUNT プロトコルを含みません。
クライアントがサーバーからファイルシステムをマウントするとき、クライアントはサーバーからファイルハンドルを取得する必要があります。ファイルハンドルは、そのファイルシステムに対応していなければなりません。そのためには、クライアントとサーバーの間でいくつかのトランザクションが発生します。この例では、クライアントはサーバーから /home/terry をマウントします。snoop によって追跡したトランザクションは、次のとおりです。
client -> server PORTMAP C GETPORT prog=100005 (MOUNT) vers=3 proto=UDP server -> client PORTMAP R GETPORT port=33492 client -> server MOUNT3 C Null server -> client MOUNT3 R Null client -> server MOUNT3 C Mount /export/home9/terry server -> client MOUNT3 R Mount OK FH=9000 Auth=unix client -> server PORTMAP C GETPORT prog=100003 (NFS) vers=3 proto=TCP server -> client PORTMAP R GETPORT port=2049 client -> server NFS C NULL3 server -> client NFS R NULL3 client -> server NFS C FSINFO3 FH=9000 server -> client NFS R FSINFO3 OK client -> server NFS C GETATTR3 FH=9000 server -> client NFS R GETATTR3 OK
この追跡結果では、クライアントがまずマウントポート番号を NFS サーバーの portmap サービスに要求します。クライアントが取得したマウントポート番号 (33492) は、サーバーでサービスが使用可能かどうかをテストするために使用されます。このポート番号でサービスが実行中であることが確認できると、クライアントはマウントを要求します。サーバーはこの要求に応答するときに、マウントするファイルシステムのファイルハンドル (9000) を指定します。これに対してクライアントは、NFS ポート番号を要求します。クライアントはサーバーからポート番号を受け取ると、NFS サービス (nfsd) が使用可能かどうかをテストします。また、そのファイルハンドルを使うファイルシステムに関する NFS 情報を要求します。
次の追跡結果では、クライアントは public オプションを使ってファイルシステムをマウントしています。
client -> server NFS C LOOKUP3 FH=0000 /export/home9/terry server -> client NFS R LOOKUP3 OK FH=9000 client -> server NFS C FSINFO3 FH=9000 server -> client NFS R FSINFO3 OK client -> server NFS C GETATTR3 FH=9000 server -> client NFS R GETATTR3 OK
デフォルトの公開ファイルハンドル (0000) を使用しているために、すべてのトランザクションにポートマップサービスから情報が与えられ、NFS ポート番号を決定するためのトランザクションはありません。
-public オプションを使用すると、マウントが失敗することがあります。NFS URL を組み合わせると、状況がさらに複雑になる可能性があります。これらのオプションを使用した場合にファイルシステムがどのようにマウントされるかは、次のとおりです。
public オプションと NFS URL – 公開ファイルハンドルが使用されます。公開ファイルハンドルがサポートされていないと、マウントは失敗します。
public オプションと通常のパス – 公開ファイルハンドルが使用されます。公開ファイルハンドルがサポートされていないと、マウントは失敗します。
NFS URL のみ – NFS サーバーでサポートされていれば、公開ファイルハンドルを使用します。公開ファイルハンドルを使用してマウントが失敗する場合は、MOUNT プロトコルを使ってマウントします。
通常のパスのみ – 公開ファイルハンドルは使用しないでください。MOUNT プロトコルが使用されます。
クライアント側のフェイルオーバー機能を使用すると、NFS クライアントは同じデータを利用できる複数のサーバーを知ることができるため、現在のサーバーが使用不能になっても、ほかのサーバーに切り替えることができます。ファイルシステムが使用不能になる原因には次のものがあります。
ファイルシステムが、クラッシュしているサーバーに接続している
サーバーの過負荷
ネットワーク障害
通常、このような場合のフェイルオーバー機能はユーザーにはわかりません。つまり、フェイルオーバー機能はクライアント上のプロセスを中断することなく実行されます。
フェイルオーバー機能が行われるためには、ファイルシステムが読み取り専用でマウントされている必要があります。また、ファイルシステムが完全に同じでないとフェイルオーバー機能は成功しません。ファイルシステムが同一になる条件については、「複製されたファイルシステムとは」を参照してください。フェイルオーバー機能の候補としては、静的なファイルシステム、または変更の少ないファイルシステムが適しています。
同じ NFS マウント上では、CacheFS 機能とクライアント側のフェイルオーバー機能の両方は使用できません。CacheFS ファイルシステムは、それぞれについて追加情報が格納されています。この情報はフェイルオーバーの際に更新できないため、ファイルシステムをマウントするときにはフェイルオーバー機能と CacheFS のどちらか片方の機能しか使用できません。
各ファイルシステムについて用意すべき複製の数を決める要素はさまざまです。理想的には、サーバーを 2 台以上設置します。それぞれのサーバーが複数のサブネットをサポートする必要があります。これは、各サブネットに一意のサーバーを設置するよりもよい方法です。フェイルオーバー処理の際にはリストにある各サーバーが確認されます。そのため、サーバーの台数を増やすと、それぞれのマウント処理が遅くなります。
フェイルオーバー機能のプロセスを完全に理解するには、次の 2 つの用語を理解する必要があります。
フェイルオーバー – 複製されたファイルシステムをサポートしているサーバーのリストから、1 つのサーバーを選択するプロセス。通常、ソートされたリストの順番を元に、次のサーバーが応答するならばそのサーバーが使用されます。
再マッピング – 新しいサーバーを使用すること。クライアントは、正常な状態のときにリモートファイルシステム上のアクティブなファイルのそれぞれのパス名を格納します。再マッピング時には、そのパス名に基づいて新しいサーバー上のファイルを検出します。
フェイルオーバー機能に関して、あるファイルシステムのすべてのファイルが元のファイルシステムのファイルとサイズもファイルタイプも同じ場合に、そのファイルシステムを 「複製」といいます。アクセス権、作成日付などのファイル属性は関係ありません。ファイルサイズまたはファイルタイプが異なると再マッピングは失敗し、元のサーバーが再び使用可能になるまでプロセスはハングアップします。NFS version 4 では、動作が異なります。「NFS version 4 におけるクライアント側フェイルオーバー機能」を参照してください。
rsync や cpio などのファイル転送メカニズムを使用することで、複製されたファイルシステムを維持できます。複製されたファイルシステムを更新すると不一致が発生するため、最良の結果を得るには次の予防策を考慮してください。
新しいバージョンのファイルをインストールするときは、あらかじめ古いバージョンのファイル名を変更する
クライアントがほとんど使用しない夜間に更新を実行する
更新は小規模にとどめる
コピーの数を最小限にする
ソフトウェアパッケージの一部は、ファイルに読み取りロックをかける必要があります。そのようなソフトウェアが正常に動作できるようにするため、読み取り専用ファイルシステムに対しても読み取りロックがかけられるようになっています。ただし、これはクライアント側でしか認識されません。サーバー側で意識されないため、再マッピングされてもロックはそのまま残ります。ファイルはもともと変更が許されないので、サーバー側でファイルをロックする必要はありません。
NFS version 4 では、ファイルサイズが違うまたはファイルタイプが同じでないために複製が確立されない場合、次のことが起こります。
ファイルが使用不能とマークされる。
警告が出力される。
アプリケーションがシステムコールの失敗を受け取る。
注 - アプリケーションを再起動して、ファイルに再度アクセスすると、正常にアクセスできます。
NFS version 4 では、サイズが異なるディレクトリの複製エラーを受け取ることはありません。以前のバージョンの NFS では、この状態はエラーとして扱われ、再マッピングプロセスを妨げました。
さらに、NFS version 4 では、ディレクトリ読み取り操作が正常に行われない場合、次に一覧表示されたサーバーによって操作が行われます。以前のバージョンの NFS では、正常でない読み取り操作により、再マッピングが失敗し、プロセスは元のサーバーが使用可能になるまで停止しました。
NFS サーバーログ機能は NFS の読み取りと書き込み、およびこのファイルシステムを変更する操作の記録を提供します。このデータは情報へのアクセスを追跡するのに利用できます。さらに、この記録は、情報へのアクセスを測定する定量的な方法を提供します。
ログ機能が有効になっているファイルシステムにアクセスすると、カーネルが raw データをバッファーファイルに書き込みます。このデータには、次の内容が含まれています。
タイムスタンプ
クライアントの IP アドレス
要求者の UID
アクセスされているファイルまたはディレクトリオブジェクトのファイルハンドル
発生した処理のタイプ
nfslogd デーモンはこの raw データを、ログファイルに保存される ASCII レコードに変換します。使用可能なネームサービス機能が一致しているものを見つけると、その変換中に IP アドレスはホスト名に変更され、UID はログインに変更されます。ファイルハンドルはパス名にも変換されます。デーモンはファイルハンドルを追跡し、情報を別のファイルハンドルパステーブルに保存して、変換を完了します。このようにすると、ファイルハンドルにアクセスされるたびに、パスを識別し直す必要がなくなります。nfslogd をオフにするとファイルハンドルパステーブルのマッピングが変更されなくなるため、デーモンは常に実行させておく必要があります。
注 - サーバーロギングは NFS version 4 ではサポートされません。
WebNFS サービスとは、あるディレクトリに置かれたファイルを、公開ファイルハンドルを使ってクライアントからアクセスできるようにするものです。ファイルハンドルは、NFS クライアントがファイルを識別できるようにカーネルが生成するアドレスです。公開ファイルハンドルの値はあらかじめ決まっているため、サーバーがクライアントに対してファイルハンドルを生成する必要はありません。定義済みのファイルハンドルを使用するというこの機能によって、MOUNT プロトコルが不要になってネットワークトラフィックが減り、クライアントにとってはプロセスが高速化します。
デフォルトでは、NFS サーバーの公開ファイルハンドルはルートファイルシステムに対して設定されます。このデフォルトのため、サーバーに対してマウント権限を持っているすべてのクライアントに対して WebNFS アクセス権が与えられます。公開ファイルハンドルは、share コマンドによって任意のファイルシステムに切り替えることができます。
あるファイルシステムに対するファイルハンドルをクライアントが持っているとき、アクセスするファイルに対応するファイルハンドルを知るには LOOKUP を実行します。NFS プロトコルでは、パス名のコンポーネントを 1 度に 1 つしか評価できません。したがって、ディレクトリ階層のレベルが 1 つ増えるたびに 1 回ずつ LOOKUP を実行します。公開ファイルハンドルからの相対パスに対して LOOKUP を実行する場合には、WebNFS サーバーはマルチコンポーネントルックアップによって 1 度にパス名全体を評価できます。マルチコンポーネントルックアップにより、WebNFS サーバーはパス名の中のディレクトリレベルを 1 つずつファイルハンドルに変換しなくても目的のファイルに対するファイルハンドルを配信できます。
また、NFS クライアントは、単一の TCP 接続を介して、複数のファイルを同時にダウンロードすることができます。このようにして接続すると、サーバーに複数の接続を設定することによる負荷をかけることなく、すばやくアクセスすることができます。Web ブラウザアプリケーションも複数ファイルを同時にダウンロードできますが、それぞれのファイルに独自の接続が確立されます。WebNFS ソフトウェアは接続を 1 つしか使用しないため、サーバーに対するオーバーヘッドを軽減できます。
パス名の中の最後のコンポーネントが他のファイルシステムに対するシンボリックリンクである場合、通常の NFS アクティビティーによってあらかじめそのファイルへのアクセス権を持っていれば、クライアントはそのファイルにアクセスできます。
通常、NFS URL は公開ファイルハンドルからの相対位置として評価されます。パスの先頭にスラッシュを 1 つ追加すると、サーバーのルートファイルシステムからの相対位置に変更できます。次の例では、公開ファイルハンドルが /export/ftp ファイルシステムに設定されていればこの 2 つの NFS URL は同等です。
nfs://server/junk nfs://server//export/ftp/junk
注 - NFS version 4 プロトコルは、WebNFS サービスに優先します。NFS version 4 は、MOUNT プロトコルと WebNFS サービスに追加されたすべてのセキュリティーネゴシエーションを完全に統合します。
NFS サービスには、WebNFS クライアントが WebNFS サーバーと、選択されたセキュリティーメカニズムについてネゴシエーションできるようにするプロトコルが含まれています。この新しいプロトコルは、セキュリティーネゴシエーションマルチコンポーネントルックアップを使用しています。これは、WebNFS プロトコルの以前のバージョンで使用されていたマルチコンポーネントルックアップの拡張版です。
WebNFS クライアントは、公開ファイルハンドルを使って通常のマルチコンポーネントルックアップ要求を行うことにより、このプロセスを開始します。このクライアントには、サーバーがどのようにしてこのパスを保護しているかについての知識がないため、デフォルトのセキュリティーメカニズムが使用されます。デフォルトのセキュリティーメカニズムでは不十分な場合は、サーバーは AUTH_TOOWEAK エラーを返します。このメッセージは、そのデフォルトメカニズムが有効ではなく、クライアントはより強力なメカニズムを使用する必要があることを意味しています。
クライアントは、AUTH_TOOWEAK エラーを受信すると、サーバーに対してどのセキュリティーメカニズムが必要か決定するように要求します。この要求が成功すると、サーバーは、指定されたパスに必要なセキュリティーメカニズムの配列を返します。このセキュリティーメカニズムの配列のサイズによっては、クライアントは完全な配列を得るためにさらに要求を出さなければならない場合があります。サーバーが WebNFS セキュリティーネゴシエーションをサポートしていない場合は、この要求は失敗します。
要求が成功すると、WebNFS クライアントは、クライアントがサポートしている最初のセキュリティーメカニズムを配列から選択します。その後、クライアントは、選択したセキュリティーメカニズムを使用して、通常のマルチコンポーネントルックアップ要求を発行し、ファイルハンドルを獲得します。この後に続くすべての NFS 要求は、選択されたセキュリティーメカニズムとファイルハンドルを使って出されます。
注 - NFS version 4 プロトコルは、WebNFS サービスに優先します。NFS version 4 は、MOUNT プロトコルと WebNFS サービスに追加されたすべてのセキュリティーネゴシエーションを完全に統合します。
HTTP を使用する Web サイトで実現可能な機能のいくつかは、WebNFS ではサポートされていません。この違いは、NFS サーバーはファイルを送るだけであるため、特別な処理はすべてクライアントで行う必要があることが原因です。ある Web サイトを WebNFS と HTTP 両方のアクセスに対応させるには、次を考慮してください。
NFS によるブラウズでは CGI スクリプトは実行されません。したがって、CGI スクリプトを多用している Web サイトを含むファイルシステムは、NFS によるブラウズに適していない可能性があります。
ブラウザからは、形式の異なるファイルを扱うために別のビューアが起動されることがあります。NFS URL からそうしたファイルにアクセスすると、ファイル名からファイルタイプが判別できるならば外部のビューアが起動されます。ブラウザは、NFS URL が使用されている場合、標準の MIME タイプで決まっているファイル名拡張子をすべて認識します。WebNFS ソフトウェアは、ファイルの内容からファイルタイプを判別しません。したがって、ファイルタイプはファイル名の拡張子だけから判別されます。
NFS によるブラウズでは、サーバー側のイメージマップ (クリック可能なイメージ) は使用できません。ただし、クライアント側のイメージマップ (クリック可能なイメージ) は、場所とともに URL が定義されているため使用できます。ドキュメントサーバーからの応答は不要です。
NFS 環境は、アーキテクチャーやオペレーティングシステムの異なるコンピュータから構成されるネットワーク上でファイルシステムを共有するために、有力で使いやすい手段です。しかし、NFS の操作によるファイルシステムの共有を便利にする機能が、一方ではセキュリティー上の問題につながっています。今まで、NFS はほとんどのバージョンで UNIX (AUTH_SYS) 認証を使用してきましたが、現在では AUTH_DH のようなより強力な認証方式も使用可能です。UNIX 認証を使用している場合、NFS サーバーは、要求をしたユーザーではなくコンピュータを認証して、ファイル要求を認証します。そのため、クライアントユーザーは、su を実行してファイルの所有者を装ったりすることができます。DH 認証では、NFS サーバーはユーザーを認証するため、このような操作が困難になります。
スーパーユーザーのアクセス権とネットワークプログラミングについての知識があれば、だれでも任意のデータをネットワークに取り入れたり、ネットワークから取り出したりできます。ネットワークに対するもっとも危険な攻撃は、データをネットワークに持ち込むような攻撃です。たとえば、有効なパケットを生成したり、または「対話」を記録し後で再生することによってユーザーを装うなどの手段があります。これらはデータの整合性に影響を与えます。ユーザーを装わず、単にネットワークトラフィックを傍受するための盗聴が行われる攻撃であれば、データの整合性が損なわれることはないため、それほど危険ではありません。ネットワーク上でやりとりされるデータを暗号化すると、機密情報のプライバシを保護できます。
ネットワークのセキュリティー問題に対する共通の対処方法は、解決策を各アプリケーションにゆだねることです。さらに優れた手法としては、すべてのアプリケーションを対象として、標準の認証システムを導入することです。
Oracle Solaris オペレーティングシステムには、NFS の操作が構築されるメカニズムであるリモート手続き呼び出し (RPC) のレベルで、認証システムが組み込まれています。このシステムは Secure RPC と呼ばれ、ネットワーク環境のセキュリティーを大幅に向上させるとともに、NFS のセキュリティーを強化します。Secure RPC の機能を利用した NFS システムを Secure NFS システムといいます。
Secure RPC は Secure NFS システムの基本となるメカニズムです。Secure RPC の目標は、少なくともタイムシェアリングシステム程度に安全なシステムを構築することです。タイムシェアリングシステムでは、すべてのユーザーが 1 台のコンピュータを共有します。タイムシェアリングシステムはログインパスワードによりユーザーを認証します。データ暗号化規格 (DES) 認証でも、同じ認証処理が実行されます。ユーザーは、ローカル端末の場合と同じように、任意のリモートコンピュータにログインできます。ユーザーのログインパスワードは、ネットワークセキュリティーへの保証です。タイムシェアリングでは、システム管理者は信頼のおける人で、パスワードを変更してだれかを装うようなことはしないという道徳上の義務を負います。Secure RPC では、ネットワーク管理者は「公開鍵」を格納するデータベースのエントリを変更しないという前提で信頼されています。
RPC 認証システムを理解するには、 「資格 (credential)」と「ベリファイア」という 2 つの用語を理解する必要があります。ID バッジを例にとれば、 資格とは、名前、住所、誕生日など個人を識別するものです。ベリファイアとはバッジに添付された写真です。バッジの写真をその所持者と照合することによって、そのバッジが盗まれたものではないことを確認できます。RPC では、クライアントプロセスは RPC 要求のたびに資格とベリファイアの両方をサーバーに送信します。クライアントはサーバーの資格をすでに知っているため、サーバーはベリファイアだけを送り返します。
RPC の認証機能は拡張が可能で、UNIX、DH、および KERB などのさまざまな認証システムを組み込むことができます。
ネットワークサービスで UNIX 認証を使用する場合、資格にはクライアントのホスト名、UID、GID、グループアクセスリストが含まれ、ベリファイアには何も含まれません。ベリファイアが存在しないため、root ユーザーは su などのコマンドを使用して、適切な資格を偽ることができます。UNIX 認証でのもう 1 つの問題は、ネットワーク上のすべてのコンピュータを UNIX コンピュータと想定していることです。UNIX 認証を異機種ネットワーク内の他のオペレーティングシステムに適用した場合、これは正常に動作しません。
UNIX 認証の問題を克服するために、Secure RPC では DH 認証を使用します。
DH 認証は、Data Encryption Standard (DES) と Diffie-Hellman 公開鍵暗号手法を使ってネットワーク上のユーザーとコンピュータの両方を認証します。DES は、標準の暗号化メカニズムです。Diffie-Hellman 公開鍵暗号手法は、2 つの鍵、つまり公開鍵と秘密鍵を持つ暗号方式です。 公開鍵と秘密鍵は名前空間に格納されます。NIS では、これらの鍵は public-key マップに保存されています。これらのマップにはすべての認証の候補ユーザーの公開鍵と秘密鍵が入っています。このマップの設定方法については、『Oracle Solaris Administration: Naming and Directory Services 』を参照してください。
DH 認証のセキュリティーは、送信側が現在時間を暗号化する機能に基づいていて、受信側はこれを復号化して、自分の時間と照合します。タイムスタンプは DES を使用して暗号化されます。このスキームが機能するには次の条件が必要です。
2 つのエージェントの現在時間が一致している。
送信側と受信側が同じ暗号化鍵を使用する。
ネットワークが時間同期プログラムを実行する場合、クライアントとサーバー上の時間は自動的に同期がとられます。時間同期プログラムを使用できない場合、ネットワーク時間ではなく、サーバーの時間を使ってタイムスタンプを計算できます。クライアントは、RPC セッションを開始する前にサーバーに時間を要求し、自分のクロックとサーバーのクロックとの時間差を計算します。タイムスタンプを計算するときには、この差を使ってクライアントのクロックを補正します。クライアントとサーバーのクロックが同期していないと、サーバーはクライアントの要求を拒否します。その場合、クライアントの DH 認証システムはサーバーとの間で再び同期をとります。
クライアントとサーバーは、ランダムな「対話鍵」(「セッション鍵」とも呼ばれる) を生成したあと公開鍵暗号方式を使って「共通鍵」を推理することによって、同一の暗号化鍵に到達します。この共通鍵は、クライアントとサーバーだけが推理できる鍵です。対話鍵は、クライアントのタイムスタンプを暗号化および復号化するために使用されます。共通鍵は、この対話鍵を暗号化および復号化するために使用されます。
Kerberos は、マサチューセッツ工科大学 (MIT) で開発された認証システムです。Kerberos は、DES を含むさまざまな暗号化タイプを提供します。Kerberos のサポートは、Secure RPC の一部としてはもう提供されていませんが、このリリースにはサーバー側とクライアント側の実装が含まれています。Kerberos 認証の実装についての詳細は、『Oracle Solaris 11.1 の管理: セキュリティーサービス』の第 19 章「Kerberos サービスについて」を参照してください。
Secure RPC を使用する場合は、次の点に注意してください。
サーバーがクラッシュしたとき周囲にだれもいない場合 (停電のあとなど) には、システムに格納されていた秘密鍵はすべて削除されます。そのためどのプロセスからも、セキュアなネットワークサービスにアクセスしたり NFS ファイルシステムをマウントしたりできません。リブート中の重要な処理は、通常 root として実行されます。そのため、root の秘密鍵を別に保存していればこれらのプロセスを実行できますが、その秘密鍵を復号化するパスワードを入力することはできません。keylogin -r を使用すると root の秘密鍵がそのまま /etc/.rootkey に格納され、keyserv がそれを読み取ります。
システムによっては、シングルユーザーモードでブートし、コンソールには root のログインシェルが表示されてパスワードの入力が要求されないことがあります。このような場合は、物理的なセキュリティーが不可欠です。
ディスクレスコンピュータのブートは、完全に安全とはいえません。ブートサーバーになりすましてリモートコンピュータに対する秘密鍵の入力を記録するような、不正なカーネルをだれかがブートすることが考えられます。Secure NFS システムによって保護されているのはカーネルと鍵サーバーが起動した後だけです。そうでないと、ブートサーバーからの応答を認証することができません。このような制限は重大な問題につながる可能性がありますが、この部分を攻撃するにはカーネルのソースコードを使用した高度な技術が必要です。また、不法行為の痕跡が残ります。つまり、ネットワークを通じてブートサーバーにポーリングすれば、不正なブートサーバーの場所がわかります。
多くの setuid プログラムは root が所有者です。root の秘密鍵が /etc/.rootkey に格納されていれば、これらのプログラムは正常に動作します。しかし、ユーザーが所有者である setuid プログラムは動作しない可能性があります。たとえば、ある setuid プログラムの所有者が dave であり、ブート後 dave が 1 度もログインしていないとします。このプログラムはセキュアなネットワークサービスにはアクセスできません。
リモートコンピュータに (login、rlogin、または telnet を使用して) ログインし、keylogin を使ってアクセスすると自分のアカウントへのアクセスを許したことになります。これは、秘密鍵が相手側のコンピュータの鍵サーバーに渡され、鍵サーバーがその秘密鍵を格納したためです。このプロセスが問題になるのは、相手側のリモートコンピュータを信用できない場合だけです。しかし、疑いがある場合は、パスワードを要求するリモートコンピュータにはログインしないでください。代わりに NFS 環境を使用して、そのリモートコンピュータから共有されているファイルシステムをマウントします。または、keylogout を使って鍵サーバーから秘密鍵を消去します。
ホームディレクトリが共有されていて -o sec=dh 指定されていると、リモートログインによって問題が生じる可能性があります。/etc/hosts.equiv ファイルまたは ~/.rhosts ファイルに、パスワードを要求するように設定されていない場合は、ログインが成功します。ただし、ローカルで認証されていないため、ユーザーは自分のホームディレクトリにアクセスできません。パスワードを要求され、入力したパスワードがネットワークパスワードと一致すれば、自分のホームディレクトリにアクセスできます。
|