以下の節では、NFS の複雑な機能をいくつか紹介します。
NFS サーバーがサポートしているクライアントが NFS バージョン 3 を使用していない場合に備えて、開始手順にはプロトコルレベルのネゴシエーションが含まれています。クライアントとサーバーの両方がバージョン 3 をサポートしていると、バージョン 3 が使用されます。どちらか片方でもバージョン 2 しかサポートしていないと、バージョン 2 が使用されます。
ネゴシエーションによって決まった値は、mount コマンドに -vers オプションを使用して変更できます。mount_nfs(1M) のマニュアルページを参照してください。ほとんどの場合、デフォルトによって最適なバージョンが選択されるため、ユーザーが指定する必要はありません。
開始時には、トランスポートプロトコルもネゴシエートされます。デフォルトでは、クライアントとサーバーの両方がサポートしているコネクション型トランスポートの中で最初に見つかったものが選択されます。それが見つからない場合は、コネクションレス型トランスポートプロトコルの中で最初に見つかったものが使用されます。システムでサポートされているトランスポートプロトコルのリストは、/etc/netconfig にあります。TCP はコネクション型トランスポートプロトコルで、Solaris 2.6 からサポートされています。UDP はコネクションレス型トランスポートプロトコルです。
NFS プロトコルのバージョンとトランスポートプロトコルが両方ともネゴシエーションによって決まった場合は、NFS プロトコルのバージョンがトランスポートプロトコルよりも優先されます。UDP を使用する NFS バージョン 3 プロトコルの方が、TCP を使用する NFS バージョン 2 プロトコルよりも優先されます。 mount コマンドでは NFS プロトコルのバージョンもトランスポートプロトコルも手動で選択できます。mount_nfs(1M) のマニュアルページを参照してください。ほとんどの場合、ネゴシエーションによって選択されるオプションの方が適切です。
ファイル転送サイズは、クライアントとサーバーの間でデータを転送するときに使用されるバッファーのサイズです。原則として、ファイル転送サイズが大きいほどパフォーマンスが向上します。NFS バージョン 3 には転送サイズに上限はありませんが、Solaris 2.6 以降がデフォルトで提示するバッファーサイズは 32K バイトです。クライアントは、必要であればマウント時にこれより小さい転送サイズを提示することができますが、ほとんどの場合その必要はありません。
転送サイズは、NFS バージョン 2 を使用しているシステムとはネゴシエートされません。このとき、ファイル転送サイズの上限は 8K バイトに設定されます。
mount コマンドに対して -rsize オプションと -wsize オプションを使用すると、転送サイズを手動で設定できます。PC クライアントの一部では転送サイズを小さくする必要があります。また、NFS サーバーが大きなファイル転送サイズに設定されている場合は、転送サイズを大きくすることができます。
クライアントがサーバーからファイルシステムをマウントするとき、クライアントはサーバーからファイルハンドルを取得する必要があります。ファイルハンドルは、そのファイルシステムに対応していなければなりません。そのためには、クライアントとサーバーの間でいくつかのトランザクションが発生します。この例では、クライアントはサーバーから /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) を ping します。また、そのファイルハンドルを使うファイルシステムに関する 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 つのサーバーを選択するプロセス。通常、ソートされたリストの順番を元に、次のサーバーが応答するならばそのサーバーが使用される
再マッピング – 新しいサーバーを使用すること。クライアントは、正常な状態のときにリモートファイルシステム上のアクティブなファイルのそれぞれのパス名を格納する。再マッピング時には、そのパス名に基づいて新しいサーバー上のファイルを検出する
フェイルオーバー機能に関して、あるファイルシステムのすべてのファイルが元のファイルシステムのファイルとサイズも vnode タイプも同じ場合に、そのファイルシステムを「複製」といいます。アクセス権、作成日付などのファイル属性は関係ありません。ファイルサイズまたは vnode タイプが異なると再マッピングは失敗し、元のサーバーが再び使用可能になるまでプロセスはハングします。
複製されたファイルシステムを保守するには、rdist や cpio などのファイル転送メカニズムを使います。複製されたファイルシステムを更新すると不整合が発生するので、できるだけ以下を守ってください。
新しいバージョンのファイルをインストールするときは、あらかじめ古いバージョンのファイル名を変更する
クライアントによる使用が少ない夜間に更新を実行する
更新は小規模にとどめる
コピーの数を最小限にする
ソフトウェアパッケージの一部は、ファイルに読み取りロックをかける必要があります。そのようなソフトウェアが正常に動作できるようにするため、読み取り専用ファイルシステムに対しても読み取りロックがかけられるようになっています。ただし、これはクライアント側でしか認識されません。サーバー側で意識されないため、再マッピングされてもロックはそのまま残ります。ファイルはもともと変更が許されないので、サーバー側でファイルをロックする必要はありません。
Solaris 2.6 およびその互換バージョンでは、2G バイトを超えるファイルを扱えます。デフォルトでは、UFS ファイルシステムはこの新機能を活かすために -largefiles オプション付きでマウントされます。以前のリリースでは、2G バイトを超えるファイルは扱えません。具体的な方法については NFS サーバー上で大規模ファイルを無効にする方法 を参照してください。
-largefiles オプションを使ってサーバー上のファイルシステムをマウントする場合、大規模ファイルにアクセスするために Solaris 2.6 NFS クライアントを変更する必要はありません。ただし、Solaris 2.6 のコマンドすべてで大規模ファイルを扱えるわけではありません。大規模ファイルを扱えるコマンドについては、largefile(5) を参照してください。大規模ファイル用機能拡張を備えた NFS バージョン 3 プロトコルをサポートしていないクライアントは、大規模ファイルには一切アクセスできません。Solaris 2.5 クライアントでは、NFS バージョン 3 プロトコルを使用することはできますが、大規模ファイルを扱う機能は含まれていません。
NFS サーバーログ機能は NFS の読み取りと書き込み、およびこのファイルシステムを変更する操作の記録を提供します。このデータは情報へのアクセスを追跡するのに利用できます。さらに、この記録は、情報へのアクセスを測定する定量的な方法を提供します。
ログ機能が有効になっているファイルシステムにアクセスすると、カーネルが raw データをバッファーファイルに書き込みます。このデータには、次の内容が含まれています。
タイムスタンプ
クライアントの IP アドレス
要求者の UID
アクセスされているファイルまたはディレクトリオブジェクトのファイルハンドル
発生した処理のタイプ
nfslogd デーモンはこの raw データを、ログファイルに保存される ASCII レコードに変換します。使用可能なネームサービス機能が一致しているものを見つけると、その変換中に IP アドレスはホスト名に変更され、UID はログインに変更されます。ファイルハンドルはパス名にも変換されます。デーモンはファイルハンドルを追跡し、情報を別のファイルハンドルパステーブルに保存して、変換を完了します。このようにすると、ファイルハンドルにアクセスされるたびに、パスを識別し直す必要がなくなります。nfslogd をオフにするとファイルハンドルパステーブルのマッピングが変更されなくなるため、デーモンは常に実行させておく必要があります。
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 |
Solaris 8 リリースから、WebNFS クライアントが WebNFS サーバーと、選択されたセキュリティメカニズムについてネゴシエーションできるようにする新しいプロトコルがあります。この新しいプロトコルは、セキュリティネゴシエーションマルチコンポーネントルックアップを使用しています。これは、WebNFS プロトコルの以前のバージョンで使用されていたマルチコンポーネントルックアップの拡張版です。
WebNFS クライアントは、公共ファイルハンドルを使って通常のマルチコンポーネントルックアップ要求を行うことにより、このプロセスを開始します。このクライアントには、サーバーがどのようにしてこのパスを保護しているかについての知識がないため、デフォルトのセキュリティメカニズムが使用されます。デフォルトのセキュリティメカニズムでは不十分な場合は、サーバーは AUTH_TOOWEAK エラーを返します。このメッセージは、そのデフォルトメカニズムが有効ではなく、クライアントはより強力なメカニズムを使用する必要があることを意味しています。
クライアントは、AUTH_TOOWEAK エラーを受信すると、サーバーに対してどのセキュリティメカニズムが必要か決定するように要求します。この要求が成功すると、サーバーは、指定されたパスに必要なセキュリティメカニズムの配列を返します。このセキュリティメカニズムの配列のサイズによっては、クライアントは完全な配列を得るためにさらに要求を出さなければならない場合があります。サーバーが WebNFS セキュリティネゴシエーションをサポートしていない場合は、この要求は失敗します。
要求が成功すると、WebNFS クライアントは、クライアントがサポートしている最初のセキュリティメカニズムを配列から選択します。その後、クライアントは、選択したセキュリティメカニズムを使用して、通常のマルチコンポーネントルックアップ要求を発行し、ファイルハンドルを獲得します。この後に続くすべての NFS 要求は、選択されたセキュリティメカニズムとファイルハンドルを使って出されます。
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 サーバーはユーザーを認証するため、このような操作が困難になります。
スーパーユーザーへのアクセス権とネットワークプログラミングについての知識があれば、誰でも任意のデータをネットワークに入れ、ネットワークから任意のデータを取り出すことができます。ネットワークに対するもっとも危険な攻撃は、データをネットワークに持ち込むような攻撃です。たとえば、有効なパケットを生成したり、または「対話」を記録し後で再生することによってユーザーを装うなどの手段があります。これらはデータの整合性に影響を与えます。許可を持つユーザーを装うことなく、単にネットワークトラフィックを受信するだけの受動的な盗み聞きならば、データの整合性が損なわれることはないため、それほど危険ではありません。ネットワーク上でやりとりされるデータを暗号化すると、機密情報のプライバシを保護できます。
ネットワークのセキュリティ問題に対する共通の対処方法は、解決策を各アプリケーションにゆだねることです。さらに優れた手法としては、すべてのアプリケーションを対象として、標準の認証システムを導入することです。
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 マップに保存されています。これらのマップにはすべての認証の候補ユーザーの公開鍵と秘密鍵が入っています。このマップの設定方法については、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照してください。
DH 認証のセキュリティは、送信側が現在時刻を暗号化する機能に基づいていて、受信側はこれを復号化して、自分の時刻と照合します。タイムスタンプは DES を使用して暗号化されます。この方式が機能するには次の条件が必要です。
2 つのエージェントの現在時刻が一致している。
送信側と受信側が同じ暗号化鍵を使用する。
ネットワークが時間同期プログラムを実行する場合、クライアントとサーバー上の時間は自動的に同期されます。時間同期プログラムを使用できない場合、ネットワーク時間ではなく、サーバーの時間を使ってタイムスタンプを計算できます。クライアントは、RPC セッションを開始する前にサーバーに時間を要求し、自分のクロックとサーバーのクロックとの時間差を計算します。タイムスタンプを計算するときには、この差を使ってクライアントのクロックを補正します。サーバーがクライアントの要求を拒否するほど、クライアントとサーバーのクロック同期がずれた場合、DH 認証システムはサーバーとの間で再び同期をとります。
クライアントとサーバーは、ランダムな対話鍵 (セッションキーとも呼ばれる) を生成することによって、同じ暗号化鍵に到達します。次に、公開鍵暗号手法 (公開鍵と秘密鍵を必要とする暗号化方式) を使って共通鍵を推理します。この共通鍵は、クライアントとサーバーだけが推理できる鍵です。対話鍵は、クライアントのタイムスタンプを暗号化および復号化するために使用されます。共通鍵は、この対話鍵を暗号化および復号化するために使用されます。
Kerberos は、マサチューセッツ工科大学 (MIT) で開発された認証システムです。Kerberos での暗号化は DES に基づいています。Kerberos サポートは、現在では Secure RPC の一部としては供給されていませんが、Solaris 9 リリースには、サーバー側とクライアント側の実装が含まれています。Solaris 9 に実装されている Kerberos 認証については、『 Solaris のシステム管理 (セキュリティサービス)』の「SEAM について」を参照してください。
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 ファイルに、パスワードを要求するように設定されていない場合は、ログインが成功します。ただし、ローカルで認証されていないため、ユーザーは自分のホームディレクトリにアクセスできません。パスワードを要求され、入力したパスワードがネットワークパスワードと一致すれば、自分のホームディレクトリにアクセスできます。