EXPORTS(5) EXPORTS(5) 名前 exports - エクスポート (export) される NFS ファイルシステム 書式 /etc/exports 説明 /etc/exports ファイルはファイルシステムのアクセスコントロールリストで、 どのファイルシステムを NFS クライアントにエクスポート (export) してよい か 、 と いう情報を与える。これは NFS mount デーモン mountd(8) ならびに NFS file server デーモン nfsd(8) の双方で用いられる。 このファイルの書式は SunOS の exports ファイルとほぼ同じである。ただ し 指 定できるオプションがいくつか追加されている。それぞれの行には、マウン トポイントと、そのポイントのファイルシステムをマウントできるマシンや ネ ッ トグループのリストが書かれている。マウントパラメータのリストを括弧で くくったものを、それぞれのマシンの名前の後に置くこともできる。空行は 無 視 され、# 以降行末まではコメントとみなされる。行末にバックスラッシュを おけば、エントリは次の行に継続できる。 マシン名のフォーマット NFS クライアントはいろいろな方法で指定できる。 single host これはもっとも普通のフォーマットである。ホストの指定には、レゾル バが認識できる省略形、FQDN、IP アドレスのどれを用いてもよい。 netgroups NIS のネットグループを @group のように与えることができる。ネット グループのすべてのメンバーのうち、ホストの部分だけが取り出され、 アクセスリストに追加される。ホストの部分が空だったり、単一のダッ シュ (-) だったものは無視される。 ワイルドカード マシン名の指定には、ワイルドカード文字として * と ? を用いること が できる。これらを使うと exports ファイルをコンパクトにできる。 例えば *.cs.foo.edu はドメイン cs.foo.edu にあるすべてのホストに マッチする。ただし、これらのワイルドカード文字はドメイン名のドッ ト (.) にはマッチしない。したがって上記のパターンは、ドメイン 内 の a.b.cs.foo.edu のようなホストにはマッチしない。 IP networks ディレクトリを IP の (サブ) ネットワークに存在するすべてのホスト に同時にエクスポートすることもできる。これには IP アドレスとネッ トマスクのペアを address/netmask のように指定すればよい。 =public これは特殊な意味を持つ「ホスト名」で、その前に与えられたディレク トリが public root ディレクトリであることを示す (WebNFS と pub- lic root ハンドルの詳細に関しては nfsd(8) の WebNFS のセクション を参照のこと)。この書式を用いる際には、 =public がその行での唯一 のホスト名エントリでなければならない。またエクスポートオプション を指定してはならない。この指定によって、ディレクトリが実際にエク スポートされるわけではないことに注意すること。エクスポートオプシ ョンは、これとは別のエントリで指定する必要がある。 public root パスは nfsd を --public-root オプションを指定して起動するこ とによっても指定できる。 public root の複数指定は無視される。 一般的なオプション mountd と nfsd は以下のエクスポートオプションを受け付ける。 secure こ の オプションを指定すると、IPPORT_RESERVED (1024) より小さな internet ポートから発したリクエストしか受けつけない。このオプ シ ョンはデフォルトで有効になっている。無効にするには insecure と指 定する。 rw クライアントによるファイルとディレクトリの変更を許可する。デフォ ルトでは、クライアントは読み込みのリクエストだけに制限されている 。 (これは ro オプションで明示した場合も同じ)。 noaccess このオプションを付けたクライアントは、そのディレクトリ以下のすべ てのファイルに対してアクセスできなくなる。あるディレクトリ階層を クライアントにエクスポートするとき、特定のサブディレクトリを除き たい場合などに便利である。 noaccess フラグが付いたディレクトリの クライアントからの見え方は、非常に制限されたものとなる。ディレク ト リ属性と、‘.’ および ‘..’ の閲覧だけが許される。 readdir に対 して返されるエントリもこの 2 つだけになる。 link_relative 絶対パス形式のシンボリックリンクを相対パス形式のリンクに変換する ( 絶対パス形式とは、リンクの内容が "/" で始まるものである)。変換 は次のように行われる。まずリンクが置かれているディレクトリの、サ ー バのルートからの深さを取得する。そしてその数だけ ’../’ を絶対 リンクの前に付加する。マウントポイントのルートからの位置が異なる 場合、この変換には微妙な (おそらく障害の原因となる) あいまいさが 含まれる可能性がある。 link_absolute 全てのシンボリックリンクをそのままにする。これがデフォルトである 。 ユーザ ID のマッピング サ ーバマシン上のファイルに対する nfsd によるアクセスコントロールは、そ れぞれの NFS RPC request の際に与えられる uid と gid に基づいている。ユ ー ザは通常、サーバ上にある自分のファイルには、それが普通のファイルシス テム上にあるのと同様にアクセス可能であることを期待している。これには ク ラ イアントとサーバ上で用いられる uid と gid がそれぞれ同じである必要が あるが、これは常に真であるとは限らず、望ましいとも限らない。 クライアントマシンの root が NFS サーバのファイルにアクセスするとき、サ ー バの root として扱われてしまうのは、ほとんどの場合は望ましくない。こ のため uid 0 は普通は別の id (anonymous や nobody uid) にマッピングされ る。この動作は ‘root squashing’ と呼ばれるが、これがデフォルトである。 no_root_squash を使えばオフにできる。 デフォルトでは、 nfsd は起動時に password ファイル中の nobody ユーザ を 参照して、 anonymous の uid と gid を得ようとする。もしそれが見つからな い場合には、 uid と gid として -2 (つまり 65534) を用いる。これらの数値 は anonuid と anongid オプションによって変更できる。 こ れに加え、 nfsd によって nobody に割り当てるべき適当な uid と gid と を指定することもできる。最後に、 all_squash オプションを指定すれば、 全 ての user request を anonymous uid に割り当てることもできる。 マシンごとに uid が異なるような場合への導入を容易にするため、 nfsd では サーバの uid をクライアントの uid に (あるいはその逆に) 動的にマッピ ン グ する手法をいくつか提供している。静的なマッピングファイル、NIS ベース のマッピング、 ugidd ベースのマッピング、である。 ugidd ベースのマッピングは map_daemon オプションを指定して UGID RPC プ ロ ト コ ルを使えば可能となる。このプロトコルを動かすにはクライアントで ugidd(8) mapping デーモンを動作させる必要がある。これは 3 つある方法 の 中で、セキュリティ的には最悪である。なぜなら ugidd を動作させると、誰で もクライアントに問い合わせて、有効なユーザ名のリストを入手できてしま う からである。 ugidd へのアクセスを特定のホストのみに制限して、身を守るこ ともできる。これには許可するホストのリ ス ト を hosts.allow ま た は hosts.deny ファイルに記述すればよい。サービス名は ugidd である。これら のファイルの文法については、 hosts_access(5) を参照してほしい。 静的なマッピングは map_static オプションによって動作させることができ る 。 こ の オプションは、マッピングを記述したファイルの名前を引数にとる。 NIS ベースのマッピングは、クライアントの NIS サーバに問い合わせて、サー バ ーホストでのユーザ名およびグループ名からクライアントでのユーザ名およ びグループ名への、マッピング情報を入手する。 以下にマッピングオプションの完全なリストをあげる: root_squash uid/gid が 0 のリクエストを annonymous uid/gid にマッピングす る 。このオプションは、root 以外の uid には適用されない。他にも注意 すべき uid は存在する (例えば bin など) ので、注意する必要がある 。 no_root_squash root squashing を無効にする。このオプションは主にディスクレスク ライアントにとって便利である。 squash_uids and squash_gids このオプションは、annonymous にマッピングされる uid や gid の リ ストを明示するためのものである。 id のリストとしては以下のような 指定が有効である: squash_uids=0-15,20,25-50 通常の squash リストはもっとずっと簡単なものになるだろうが。 all_squash 全ての uid とgid を anonymous にマッピングする。これは NFS エ ク ス ポートされた公開 FTP ディレクトリや、 news のスプールディレク トリ等に便利である。これと逆のオプションは no_all_squash であ り 、こちらがデフォルトになっている。 map_daemon こ の オプションは 動的な uid/gid のマッピングを有効にする。 NFS request 中のそれぞれの uid はサーバ上の対応する uid に変換され、 NFS reply 中の uid はそれぞれ逆に変換される。このオプションを用 いるには、クライアントホストで rpc.ugidd(8) が動作していることが 必 要 である。デフォルトでは、全ての uid を変えない map_identity となっている。普通の squash オプションは、動的なマッピングか否か を気にすることなく適用できる。 map_static このオプションを指定すると静的なマッピングが可能となる。 uid/gid マッピングが記述されたファイル名を以下のように指定する。 map_static=/etc/nfs/foobar.map ファイルのフォーマットは以下のようなものである。 # Mapping for client foobar: # remote local uid 0-99 - # squash these uid 100-500 1000 # map 100-500 to 1000-1400 gid 0-49 - # squash these gid 50-100 700 # map 50-100 to 700-750 map_nis このオプションを指定すると NIS ベースの uid/gid マッピングが可能 と なる。例えば、サーバが uid 123 の指定を受けると、サーバはまず その uid に対応するローカルのログイン名を調べる。次に NFS クライ アントの NIS サーバに接続して、そのログイン名に対応する uid を取 得する。 これを行うには、NFS サーバがクライアントの NIS ドメインを知っ て い なければならない。このドメインは map_nis オプションの引数とし て以下のように指定する。 map_nis=foo.com ただここに NIS ドメインを記述するだけでは、通常は充分ではない 。 nfsd が NIS サーバにコンタクトできるようにするには、他の作業が必 要となるだろう。利用しているディストリビューションが NYS ライ ブ ラ リ を 使 っ て い る 場合は、クライアントのドメインのサーバを /etc/yp.conf に一つ以上指定する必要があるだろう。他の NIS ライブ ラ リを用いている場合には、 yp.conf によって設定できるような、特 殊な ypbind(8) を入手する必要があるかもしれない。 anonuid および anongid これらのオプションは anonymous アカウントの uid と gid を明示 的 にセットする。これは、全てのリクエストが一人のユーザからになるよ うな PC/NFS clients にとって主に有効である。例えば、以下の「例」 の セクションでの /home/joe というエクスポートエントリを見てほし い。この例では、(joe からのものであると思われる) 全てのリクエ ス トが uid 150 にマッピングされる。 例 # sample /etc/exports file / master(rw) trusty(rw,no_root_squash) /projects proj*.local.domain(rw) /usr *.local.domain(ro) @trusted(rw) /home/joe pc001(rw,all_squash,anonuid=150,anongid=100) /pub (ro,insecure,all_squash) /pub/private (noaccess) 1 行目は、master と trusty に対して、すべてのファイルシステムのマウント 許可を出している。書き込みの許可に加え、さらに trusty に対しては、す べ ての uid squashing も無効にしている。 2 行目と 3 行目は、ホスト名へのワ イルドカードの利用と、ネットグループ (@trusted’ のエントリ) の例であ る 。 4 行目は、上で述べた PC/NFS クライアント用エントリの例である。 5 行 目は、公開 FTP ディレクトリを世界中の全てのホストにエクスポートしている 。 すべてのリクエストは nobody アカウントで実行される。またこのエントリ 中の insecure オプションによって、NFS 用 port を使わないように実装さ れ た NFS クライアントからのアクセスも許可している。最後の行では、private ディレクトリへのアクセスをすべてのクライアントに対して拒否するように し ている。 警告 他の NFS Server の実装と違い、この nfsd では、例えば /usr と /usr/X11R6 のように、あるディレクトリとそのサブディレクトリとの両方を同じホスト に エ クスポートすることができる。この場合、特定の度合がもっとも高いエント リのマウントオプションが適用される。例えばクライアントホスト上のユー ザ が /usr/X11R6 のファイルにアクセスする場合は、 /usr/X11R6 のエントリで あたえられた マウントオプションが適用される。このルールは、エントリのホ スト指定がワイルドカードやネットグループのときにも適用される。 ファイル /etc/exports 返り値 nfsd(8) か mountd(8) が起動していれば、ファイルの解釈中のエラーは常に syslogd(8) を用いて報告される。 DAEMON からの NOTICE レベルとなる。その と き、未知のホスト全てが報告される。しかし起動時には named(8) が全ての ホストを知らない場合もありうる。したがってホストが見つかるたびに、そ れ らは syslogd(8) に、同じパラメータで報告される。 関連項目 mountd(8), nfsd(8) 4.2 Berkeley Distribution 11 August 1997 EXPORTS(5)
Copyright(C) linux-cmd.com All Rights Reserved. Author Takayuki Yukawa