Rechercher une page de manuel

Chercher une autre page de manuel:

exports

Autres langues

Langue: ja

Autres versions - même langue

Version: 11 August 1997 (fedora - 25/11/07)

Section: 5 (Format de fichier)

名前

exports - エクスポート (export) される NFS ファイルシステム

書式

/etc/exports

説明

/etc/exports ファイルはファイルシステムのアクセスコントロールリストで、 どのファイルシステムを NFS クライアントにエクスポート (export) してよいか、 という情報を与える。 これは NFS mount デーモン mountd(8) ならびに NFS file server デーモン nfsd(8) の双方で用いられる。

このファイルの書式は SunOS の exports ファイルとほぼ同じである。ただし指定できるオプションが いくつか追加されている。 それぞれの行には、マウントポイントと、 そのポイントのファイルシステムをマウントできる マシンやネットグループのリストが書かれている。 マウントパラメータのリストを括弧でくくったものを、 それぞれのマシンの名前の後に置くこともできる。 空行は無視され、# 以降行末まではコメントとみなされる。 行末にバックスラッシュをおけば、エントリは次の行に継続できる。

マシン名のフォーマット

NFS クライアントはいろいろな方法で指定できる。
single host
これはもっとも普通のフォーマットである。ホストの指定には、 レゾルバが認識できる省略形、FQDNIP アドレスのどれを用いてもよい。
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 と public root ハンドルの詳細に関しては nfsd(8) の WebNFS のセクションを参照のこと)。 この書式を用いる際には、 =public がその行での唯一のホスト名エントリでなければならない。 またエクスポートオプションを指定してはならない。 この指定によって、 ディレクトリが実際にエクスポートされるわけではないことに注意すること。 エクスポートオプションは、これとは別のエントリで指定する必要がある。

public root パスは nfsd--public-root オプションを指定して起動することによっても指定できる。 public root の複数指定は無視される。

一般的なオプション

mountdnfsd は以下のエクスポートオプションを受け付ける。
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) を用いる。 これらの数値は anonuidanongid オプションによって変更できる。

これに加え、 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 ドメインを記述するだけでは、通常は充分ではない。 nfsdNIS サーバにコンタクトできるようにするには、 他の作業が必要となるだろう。 利用しているディストリビューションが 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)
<zorglub> peut-on récupérer le noyau de la debian sous forme de rpm ?