このページの本文へ

Turbo-CE

資格通信

2001年02月20日 00時57分更新

文● NETWORK MAGAZINE 編集部

  • この記事をはてなブックマークに追加
  • 本文印刷

NFSマウントしたNFSサーバ上のファイルに、クライアントのスーパーユーザーが特権を持ってアクセスすることはセキュリティ上好ましくありません。これを防ぐために、NFSサーバのデフォルトでは「クライアントのスーパーユーザーがNFSアクセスする場合には特権なしユーザーとして扱う」ことになっています。このデフォルト設定を解除するために、NFSサーバ上の/etc/exportsに記述すべきオプションは何ですか。正しいものを1つ選びなさい。

  • A nobody
  • B no_root_squash
  • C non_root_mount
  • D root

解説

 Linuxの管理下にあるすべてのファイルは、その属性としてオーナー(持ち主)情報を持つ。オーナー情報は“UID”と呼ばれる数値データとして管理されている。UIDは各ユーザーを識別する数値であり、すべてのユーザーは管理者によって何らかのUIDが与えられる。たとえば、UID=501を持つユーザー「john」が作成したファイル「file1」には、オーナー情報として501が与えられることになる。このfile1がNFSによって提供される場合であっても、オーナー情報501は変わらない。

 しかし、NFSクライアントにもUID=501のユーザーがいる可能性はある。そのユーザーはjohnなのだろうか? 残念ながら、NFSサーバとNFSクライアントは独立したユーザー登録情報を持つため、NFSクライアント上のUID=501のユーザーは別の人(たとえばtanaka)かもしれない(図1)。

図1 NFSの問題点
図1 NFSの問題点

 このとき、tanakaはjohnがオーナーであるはずのfile1に対して、同じくオーナーとして振る舞うことができることになる。オーナーであれば、file1を書き換えたり削除することが自由にできる。このような事態を避けるため、ネットワーク上のすべてのLinuxシステムでは、ユーザーとUIDの関係を統一する必要がある。これにはNISネームサービスを使う。NISネームサービスでは、ユーザーとUIDの情報を一元管理できる。

 ただし、スーパーユーザーに関しては例外となる。物理的に異なる人間であるにもかかわらず、スーパーユーザーはどのシステムでもrootという名前を持ち、UIDは0である。Aというシステムのrootと、Bというシステムのrootが同じ人間であるという保証はない。これは、情報の統一や一元管理でも解決できない。

 このような理由から、NFSクライアントのユーザーrootが、NFSによって提供されたファイルに対して特権アクセスすることは禁止されている。そこで、NFSクライアントのユーザーrootが共有ファイルにアクセスするときだけ特権が剥奪される仕組みになっている(UIDをユーザーnobodyにマッピングする)。この機能は“root_squash”と呼ばれ、NFSでファイルを提供する際のデフォルト設定になる。

 ただし、NFSサーバとクライアントの管理者が同一人物の場合、このデフォルト設定を解除したほうが便利な場合がある。root_squashを解除したい場合、NFSサーバの/etc/exportsにno_root_squashオプションを指定する(画面2)。

画面2 /etc/exportsファイル
画面2 /etc/exportsファイル

つまり正解はBとなる。

カテゴリートップへ

アスキー・ビジネスセレクション

ASCII.jp ビジネスヘッドライン

ピックアップ