セクションの設定

翻訳済み言語: en | + fr | + ja | + ko | + tr

この日本語訳はすでに古くなっている + 可能性があります。 + 最近更新された内容を見るには英語版をご覧下さい。 +

設定ファイル中のディレクティブは +サーバ全体に適用されたり、特定のディレクトリやファイル、ホスト、URL にのみ +適用されるように制限したりすることができます。この文書は設定用のセクションの +コンテナや .htaccess ファイルを使って他の設定ディレクティブの +スコープを変更する方法を説明します。

設定用セクションコンテナの種類
ファイルシステムとウェブ空間
バーチャルホスト
プロクシ
どのディレクティブが使えるの?
セクションのマージ方法

参照

設定用セクションコンテナの種類

+ +

関連モジュール	関連ディレクティブ
`core` `mod_version` `mod_proxy`	`<Directory>` `<DirectoryMatch>` `<Files>` `<FilesMatch>` `<IfDefine>` `<IfModule>` `<IfVersion>` `<Location>` `<LocationMatch>` `<Proxy>` `<ProxyMatch>` `<VirtualHost>`

+ +

コンテナには二つの基本となる種類があります。ほとんどのコンテナは +各リクエストに対して評価されます。その場合、コンテナ中のディレクティブは +コンテナにマッチするリクエストにのみ適用されます。一方、 +<IfDefine>, +<IfModule>, +<IfVersion> +コンテナは +サーバの起動時と再起動時にのみ評価されます。起動時に条件が真であれば、 +コンテナ中のディレクティブはすべてのリクエストに適用されます。条件が +偽であれば、コンテナ中のディレクティブは無視されます。

+ +

<IfDefine> ディレクティブは +httpd コマンドラインで適切なパラメータが定義されたときにのみ +適用されるディレクティブを囲います。例えば次の設定では、サーバが +httpd -DClosedForNow を使って起動されたときだけすべての +リクエストを別のサイトにリダイレクトします:

+ +

+<IfDefine ClosedForNow> +Redirect / http://otherserver.example.com/ +</IfDefine> +

+ +

<IfModule> は +非常に似ていますが、代わりにサーバ上でモジュールが使用可能な場合にのみ +適用可能なディレクティブを囲います。モジュールはサーバに +静的に組み込まれているか、動的に組み込むようになっていて、設定ファイル中で +LoadModule の行がより前の +部分に書かれている必要があります。このディレクティブは特定のモジュールの +存在に関わらず設定ファイルが動作する必要がある場合にのみ使ってください。 +常に動作して欲しいディレクティブを囲むために使うべきではありません。 +存在しないモジュールに関する有用なエラーメッセージの発生を抑制してしまいますので。 +

+ +

次の例では、mod_mime_magic があるときにのみ MimeMagicFiles ディレクティブが +適用されます。

+ +

+<IfModule mod_mime_magic.c> +MimeMagicFile conf/magic +</IfModule> +

+ +

<IfVersion> +ディレクティブは +<IfDefine> や +<IfModule>と、 +とてもよく似ていますが、稼働中のサーバのバージョンが特定のバージョンの時にのみ +適用されます。様々なバージョンの httpd を様々な設定で動作させることになる場合で、 +テストスイートや巨大なネットワークでの用途を想定して、 +このモジュールは設計されています。

+ +

+ <IfVersion >= 2.1> + + # this happens only in versions greater or + # equal 2.1.0. + + </IfVersion> +

+ +

<IfDefine>, +<IfModule>, +<IfVersion> ディレクティブは +テストの前に "!" を付けることで否定の条件を適用することができます。 +また、これらのセクションはより複雑な制限を課すために入れ子にすることができます。 +

ファイルシステムとウェブ空間

+ +

最もよく使われる設定のセクションコンテナはファイルシステムやウェブ空間の +特定の場所の設定を変更するものです。まず、この二つの違いを理解することが +大切です。ファイルシステムはオペレーティングシステムから見たディスクの内容です。 +たとえば、デフォルトのインストールでは Apache は Unix ファイルシステムでは +/usr/local/apache2 に、Windows ファイルシステムでは +"c:/Program Files/Apache Group/Apache2" に存在します。 +(Apache では Windows でもパスセパレータとしてスラッシュを使うことに +気をつけてください。) 対照的に、ウェブ空間はあなたのサイトを +ウェブサーバから配信されるものとして見たもので、クライアントに見えるものです。 +デフォルトの Unix 上の Apache のインストールではウェブ空間の +/dir/ というパスはファイルシステムの +/usr/local/apache2/htdocs/dir/ というパスに対応します。 +ウェブページはデータベースや他の場所から動的に生成することもできますので、 +ウェブ空間はファイルシステムに直接マップする必要はありません。

+ +

ファイルシステムコンテナ

+ +

<Directory> ディレクティブと +<Files> ディレクティブ、それと +それらの正規表現版はディレクティブをファイルシステムの一部分に対して適用します。 +<Directory> セクションの +中のディレクティブは指定されたディレクトリとそのすべてのサブディレクトリに +適用されます。.htaccess ファイルを +使うことでも同じ効果を得ることができます。例えば、次の設定では +/var/web/dir1 とすべてのサブディレクトリに対して +ディレクトリインデックスを行ないます。

+ +

+<Directory /var/web/dir1> +Options +Indexes +</Directory> +

+ +

<Files> セクションの +中にあるディレクティブはどのディレクトリにあるかに関わらず、指定された名前の +すべてのファイルに適用されます。ですから例えば以下の設定ディレクティブが +設定ファイルの主セクションに書かれたときには、すべての場所の +private.html という名前のファイルへのアクセスを拒否します。

+ +

+<Files private.html> +Order allow,deny +Deny from all +</Files> +

+ +

ファイルシステムの特定の場所にあるファイルを指定するために、 +<Files> セクションと +<Directory> セクションを +組み合わせることができます。例えば、次の設定では +/var/web/dir1/private.html, +/var/web/dir1/subdir2/private.html, +/var/web/dir1/subdir3/private.html など、 +/var/web/dir1/ ディレクトリの下にあるすべての +private.html へのアクセスを拒否します。

+ +

+<Directory /var/web/dir1> +<Files private.html> +Order allow,deny +Deny from all +</Files> +</Directory> +

+ + +

ウェブ空間コンテナ

+ +

一方、<Location> +ディレクティブとその正規表現版は +ウェブ空間上の内容に対して設定を変更します。 +たとえば、次の設定では /private で始まる URL パスへのアクセスを制限します。 +具体的には、 +http://yoursite.example.com/private, +http://yoursite.example.com/private123, +http://yoursite.example.com/private/dir/file.html +へのリクエストや、 +他の同様に /private 文字列で始まるリクエストに +適用されます。

+ +

+<Location /private> +Order Allow,Deny +Deny from all +</Location> +

+ +

<Location> +ディレクティブはファイルシステムと関係ある必要が全くありません。 +たとえば次の例では、どのようにして特定の URL を +mod_statusで提供されている Apache +内部ハンドラにマップするかを示しています。ファイルシステムに +server-status というファイルが存在する必要はありません。

+ +

+<Location /server-status> +SetHandler server-status +</Location> +

+ + +

ワイルドカードと正規表現

+ +

<Directory>, +<Files>, +<Location> +ディレクティブでは、 C 標準ライブラリの fnmatch のように +shell スタイルのワイルドカードキャラクタが使用できます。 +"*" 文字は任意の文字列にマッチし、"?" 文字は任意の 1 文字にマッチし、 +"[seq]" は seq の任意の文字にマッチします。 +"/" 文字はどのワイルドカードでもマッチされません。 +明示的に指定する必要があります。

+ +

これより柔軟なマッチングが必要な場合は、これらのコンテナに正規表現 +(regex) 版である +<DirectoryMatch>, +<FilesMatch>, +<LocationMatch> +があり、マッチを選択するのに perl 互換正規表現を使用できます。しかし、次の設定のマージに目を通して、 +regex セクションを使用することで、ディレクティブの適用がどのように +変化するか把握しておいてください。

+ +

全ユーザディレクトリの設定を変更する、非 regex +ワイルドカードセクションは次のようになります。

+ +

+<Directory /home/*/public_html> +Options Indexes +</Directory> +

+ +

regex セクションを使用することで、画像ファイルの多くのタイプに対する +アクセスを一度に拒否できます。

+<FilesMatch \.(?i:gif|jpe?g|png)$> +Order allow,deny +Deny from all +</FilesMatch> +

+ + + +

いつ何を使うか

+ +

ファイルシステムコンテナとウェブ空間コンテナを使い分けるのは、 +実際には非常に簡単です。ファイルシステムに依存する +オブジェクトにディレクティブを適応する場合は、必ず +<Directory> か +<Files> +を使用します。ファイルシステムに依存しないオブジェクト +(データベースから生成されるウェブページなど) +にディレクティブを適用する際には、 +<Location> +を使用します。

+ +

ファイルシステム上のオブジェクトへのアクセスを制限するために、 +<Location> +を決して使用ないようにしましょう。 +同一のファイルシステム位置にマップしている、ウェブ空間位置 (URL) +が多数あって、設定した制限を迂回されてしまうかもしれないからです。 +例えば次の設定を考えてみましょう。

+ +

+<Location /dir/> +Order allow,deny +Deny from all +</Location> +

+ +

http://yoursite.example.com/dir/ +へのリクエストでは上手く動作します。しかし大文字小文字を区別しない +ファイルシステムを使っていたらどうなるでしょう? +http://yoursite.example.com/DIR/ +へのリクエストで簡単にアクセス制限を迂回されてしまいます。これに対して +<Directory> +ディレクティブを使用すると、どのように呼び出されたかに関わらず +その場所から提供される内容に適用されます。 +(例外はファイルシステムのリンクです。シンボリックリンクを使って、 +同一のディレクトリを複数のファイルシステムに設置できます。 +<Directory> +ディレクティブはパス名をリセットすることなくシンボリックリンクを +辿ります。ですから、高度なセキュリティが要求される場合は、 +適切に Options +ディレクティブを使用してシンボリックリンクを無効にするべきです。)

+ +

大文字小文字を区別するファイルシステムを使用しているから上記のことは +無関係だと思われるかもしれませんが、 +同一のファイルシステム位置に複数のウェブ空間位置をマップする方法は、 +他にいくらでもあるということを覚えていてください。 +ですからできる限りファイルシステムコンテナを使用してください。 +しかしながら一つだけ例外があります。 +<Location /> セクションはどんな URL +にも関わらず適用されるので、完全に安全です。

+ + +

バーチャルホスト

+ +

<VirtualHost> +コンテナは特定のホストに適用するディレクティブを格納します。 +一台のマシンで複数のホストを異なる設定で提供したいときに有用です。 +詳細に関してはバーチャルホストドキュメントを +ご覧下さい。

プロクシ

+ +

<Proxy> +と <ProxyMatch> +コンテナは、特定の URL にマッチする mod_proxy +プロクシサーバを経由してアクセスしたサイトに対してのみ適用される +設定ディレクティブを格納します。例えば次の設定は、cnn.com +ウェブサイトにアクセスするために用いられるプロクシサーバを +制限します。

+ +

+<Proxy http://cnn.com/*> +Order allow,deny +Deny from all +</Proxy> +

どのディレクティブが使えるの?

+ +

どのタイプの設定セクションでどのディレクティブが使用できるかは、 +ディレクティブの Context +を見てください。 +<Directory> +で使用可能なものは全て、同様に +<DirectoryMatch>, +<Files>, +<FilesMatch>, +<Location>, +<LocationMatch>, +<Proxy>, +<ProxyMatch> +セクションで使用可能です。しかしながら幾つか例外も存在します。

+ +

AllowOverride ディレクティブは +<Directory> +セクションでのみ使用可能です。
FollowSymLinks と SymLinksIfOwnerMatch の +Options は、 +<Directory> +セクションか .htaccess ファイルでのみ使用可能です。
Options ディレクティブは、 +<Files> +と <FilesMatch> +セクションでは使用できません。

セクションのマージ方法

+ +

マージの順番は以下のようになっています:

+ +

<Directory> (正規表現無し) と + .htaccess を同時に (.htaccess が許可されていれば、それが + <Directory> を上書きします) +
<DirectoryMatch> + (と <Directory ~>
<Files> と + <FilesMatch> を同時に
<Location> と + <LocationMatch> を同時に

+ +

<Directory> + 以外は、それぞれのグループは設定ファイルに現れた順番に処理されます。 + <Directory> (上のグループ 1) + はディレクトリが短いものから長いものへと処理されます。ですから、 + 例えば <Directory /var/web/dir1> は + <Directory /var/web/dir/subdir> の前に処理されます。複数の + <Directory> セクションが + 同じディレクトリに + 適用される場合は、設定ファイル中の順番に従って処理されます。 + Include + によって挿入された設定は挿入しているファイルの + Include + ディレクティブの位置にあったかのように扱われます。

+ +

<VirtualHost> セクション中のセクションは + バーチャルホストの定義の外側の対応するセクションの + 後に適用されます。これによりバーチャルホストが + メインのサーバ設定を上書きできるようなります。

+ +

mod_proxy でリクエストが処理される場合は、 + 処理順番のうち、<Directory> コンテナの部分が + <Proxy> + コンテナに取って代わられます。

+ +

後のセクションのディレクティブが前のセクションのものを上書きします。

+ + +

技術メモ

+ 実際には、名前を変換する段階 (URL + をファイル名にマップするために Alias や + DocumentRoot が使用されるところ) の直前に + <Location>/<LocationMatch> + が行なわれます。 + これらを適用した結果は変換が終わった後に完全に捨てられます。 +

例

+ +

次はマージの順番を示すための恣意的な例になっています。 +リクエスト全てに適用されるとして、本例のディレクティブは +A > B > C > D > E の順番に適用されます。

+ +

+<Location /> +E +</Location> + +<Files f.html> +D +</Files> + +<VirtualHost *> +<Directory /a/b> +B +</Directory> +</VirtualHost> + +<DirectoryMatch "^.*b$"> +C +</DirectoryMatch> + +<Directory /a/b> +A +</Directory> + +

+ +

もっと具体的な、次の例を考えてみましょう。 +<Directory> +セクションに設置されたアクセス制限に関わらず、 +<Location> +セクションが最後に評価されて、サーバへのアクセスは制限されません。 +言い換えれば、マージの順番は重要で、注意して使用してください!

+ +

+<Location /> +Order deny,allow +Allow from all +</Location> + +# Woops! This <Directory> section will have no effect +<Directory /> +Order allow,deny +Allow from all +Deny from badguy.example.com +</Directory> +

+ + + +