コンテナディレクティブの設定

このパートでは、コンテナ式 ディレクティブ に共通して使用する、動作制御とアクセス制御のためのディレクティブについて説明します。

httpd の設定ファイルに記述できるディレクティブには非常に多くの種類があります。

これらの中にはhttpd全体を制御することだけを目的としたディレクティブもありますが 、その多くは、

「コンテナ外に記述すると全体としての基本設定となり、コンテナ内に記述すると特定の範囲に対しての設定を与える。」

という振る舞いをします。

それらのディレクティブの個々の仕組みを理解して、ディレクトリ毎にを適切に設定してゆくことがhttpdの設定のポイントになるわけですが、ここではその中から、

"Options"．．． 動作に関する設定

"Order" "Deny" "Allow"．．． アクセス制御に関する設定

"AllowOverride""．．． 外部ファイルによる設定の可否の設定

という「必要にして十分な五つのディレクティブ」をピックアップして解説します。

設定ファイルへの具体的な記述例については、 を参考にしてください。

Options〜動作に関する設定

"Options" ディレクティブ は、設定対象の基本的な動作許可、制限を記述します。書式は、

Options [オプション1] [オプション2] ...

です。例えば、

のように記述します。

オプションの記述順序には特に指定はありません。

以下に設定できる[オプション]について説明します。

FollowSymLinks〜シンボリックリンクでのアクセスを許可

この "FollowSymLinks" が指定された場合、 LinuxOS の シンボリックリンク を使って別のディレクトリからアクセスすることが可能になります。

具体的には、設定対象の中の任意のディレクトリのシンボリックリンクを 設定対象以外のディレクトリ に作成しておけば、そのシンボリックリンクを HTTP で開くとオリジナルのディレクトリの内容を コンテンツ として表示することができるようになります。

振る舞いとしては、 "Alias" ディレクティブ に似ていますが、"Alias"が httpd の機能によって実現されているのに対し、"FollowSymLinks"は OS の機能を利用している点が異なります。

また、この"FollowSymLinks"ディレクティブは、元々仮想ディレクトリとしての動作を行わせる "<Location...>" コンテナには記述しても意味がありません。記述することはできますが、設定そのものは無視されます。

このディレクティブは、"Alias"と同様に、 FTPクライアント から見ることのできない位置のコンテンツの配信を可能にしますから、使い方によっては便利な機能です。

ただし便利な反面、 セキュリティ 的にはマイナスですので、もしそういう機能が必要なければ有効にはしたくないところです。

ところが、"FollowSymLinks"を無効にしてシンボリックリンクでのアクセスを禁止する設定を行ってしまうと、httpdはクライアントからリクエストを受ける度に、ファイルシステムに対して「シンボリックリンクの有無」を検査しなければらなくなってしまいます。

この検査作業は、httpdの動作に少なからず負荷を与えますから、性能を犠牲にしたくなければ"FollowSymLinks"を有効にするのが望ましい選択といえるでしょう。

現実には、"FollowSymLinks"を有効にしておいても、それによってセキュリティ上の致命的な欠陥が生じるわけではありませんから、原則としては全てのディレクトリに対して有効にしておくのがお勧めの設定といえるでしょう。

ただしコンテンツの運用上、"FollowSymLinks"を無効にしたディレクトリが必要な場合は、シンボリックリンクの検査範囲を狭めるために、ファイルシステムのできるだけ下位に配置するようにしましょう。

もちろん、セキュリティを維持するために他の選択肢があれば、それを選ぶに越したことはありません。

SymLinksIfOwnerMatch〜アカウント一致の場合リンクを許可

"FollowSymLinks" が無条件に シンボリックリンク からのアクセスを許可するのに対し、このオプションはリンク元とリンク先のシステム上の所有 アカウント が一致する場合にのみアクセスを許可します。

このオプションを有効にすると、 "FollowSymLinks" を有効にするよりも幾分 セキュリティ は向上しますし、逆に設定を無効した場合と比べると「シンボリックリンクの有無」を検査するための動作負荷もありません。

ただ httpd にとっては「所有アカウントが一致しているか否か」という検査は行わなければなりませんので、セキュリティと動作負荷のバランスでいえば"FollowSymLinks"の有効と無効の中間的なオプションといえるかもしれません。

このオプションは、例えば複数の人にホームページ公開のための コンテンツ スペースを貸し出すようなとき、貸し出したディレクトリ同士が誤って(あるいは故意に)シンボリックリンクで参照し合わないようにするために利用されます。

もしもそういう運用方法をとらないのであれば、このオプションを指定するケースはまずないでしょう。

また、このディレクティブは"FollowSymLinks"と同じく、 "<Location...>" コンテナには記述しても意味がありません。記述することはできますが、設定そのものは無視されます。

Indexes〜ディレクトリ構造を表示する

クライアント からのリクエストが、 "http://www.obenri.com/dir/" のようにディレクトリ名で行われた場合で、そのディレクトリの中に "DirectoryIndex" ディレクティブ で設定されている名前のファイルが存在しない場合、「ファイルがみつかりません。」というメッセージではなくディレクトリ構造をそのまま表示するオプションです。

解説書などの多くは、 セキュリティ 確保のために、この"Indexes"ディレクティブの指定を勧めていません。

実際のところ、作成中のコンテンツデータを FTP で送信するとき、誤って他のファイルを一緒に アップロード してしまうことはあり得ることですし、きちんと設定したつもりでも大事なディレクトリにアクセス制限をかけ忘れることもあります。

そういう点を考えると、「セキュリティホールを見つけられやすくなる」"Indexes"ディレクティブは設定しないに越したことはないでしょう。

ただ、この機能を逆に積極的に利用すれば、 アノニマスFTPサーバー の代用として使うことができます。

もちろん、クライアント側は FTPクライアント ではなく、 Webブラウザ を利用する必要がありますが、むしろそのほうが サーバー にとってもクライアントにとっても簡単で安全だといえるでしょう。

MultiViews〜応答の自動選択機能を有効にする

原則として httpd は、 クライアント からのリクエストに対して忠実にコンテンツデータを配信します。

例えば、クライアントからhttpへ、

"http://www.obenri.com/index.html"

という URL にリクエストが行われた場合、ドキュメントルート の直下に"index.html"というファイルが存在しなければ、「ページが見つかりません。」という結果が表示されてしまいます。

また、 "DirectoryIndex" ディレクティブ で、

と設定している場合で、クライントからのリクエストが、

"http://www.obenri.com/"

とディレクトリ指定で行われた場合、"index.html"も"index.htm"も存在しなければ、やはりページを開くことはできません。

ところがこの "MultiViews" オプションを指定すると、例えば 「"index.html"が見つからなければ"index.*"を探して送信する。」 という具合に、httpdはクライアントからの要求に 「比較的近い」 ファイル名を選択してリクエストに応えるようになります。

とはいえ、最近は Webブラウザ のアドレスバーに自分の手でURLをタイプしてアクセスするような機会は非常に稀で、インターネット利用者は検索エンジンとブックマークばかりで利用しているケースがほとんどでしょう。

従って、 「ユーザーのタイプミスを許容するため」 ということが目的であれば、この"MultiViews"オプションは、今ではさほど重要なものではないかもしれません。

ただ、"MultiViews"オプションにはもう一つ重要な役目があります。それは 「複数言語の振り分け機能」 です。

例えば、同じ内容を持つコンテンツを異なる言語で作成したような場合、それぞれの言語に対して異なるURLを設定したり、あるいはクライアントにホームページ上で言語を選択してもらったり、という方法が一般的です。

ところが"MultiViews"オプションを有効にすると、クライアントからのリクエストである HTTPヘッダ 含まれる「標準で利用する言語」の情報を元に、httpdが適切な言語のページを選択して配信するようになります。

具体的には、例えば WindowsOS の場合、 コントロールパネル → インターネットオプション の "全般" タブから 言語(L)... を開いたときに表示される 「言語の優先順位」 の情報がhttpdに送られるようになっています。

言語の優先順位の設定画面(WindowsXP)

これを受信したhttpdは、リクエストのあったディレクトリの中を検索し、例えば、日本語[ja]が優先されている場合は "index.html.ja" を、英語[en]が優先されている場合は "index.html.en" を、という具合に選択してクライアントに送り返す訳です。

という訳ですから、"MultiViews"は、 「複数言語のコンテンツを作成する」 という計画がある場合にのみ設定すればよいオプションといえると思います。

ExecCGI〜CGIスクリプトの実行を許可する

設定対象のディレクトリ以下の任意の位置で、 CGI スクリプト の実行を許可します。

詳細は「CGIの実行許可の設定」 を参照してください。

Includes〜SSIスクリプトの実行を許可する

設定対象のディレクトリ以下の任意の位置で、 SSI スクリプト の実行を許可します。

SSIは、スクリプトの内容によっては サーバー に大きな動作負荷を与えますので、そのことを理解できない(あるいは関心がない)誰かに利用させることは好ましくありません。

第三者が利用する コンテンツ スペースにこの"Includes"オプションを設定する場合には、その点をよく考慮してから行ってください。

もちろん、"Includes"オプションを設定しても、実際にSSIのスクリプトを使用しないのであれば httpd の動作には何ら影響を与えませんので、自分の管理下のコンテンツスペースには設定しておいても構わないでしょう。

IncludesNOEXEC〜制限付きでSSIスクリプトの実行を許可する

これも SSI スクリプト の実行許可オプションですが、SSIスクリプトの中で "exec コマンド " の実行のみが禁止されます。

SSIの"execコマンド"とは、SSIから サーバー 上のSSI以外の スクリプト を実行するコマンドです。

具体的には、 WBEL や CentOS の標準のコマンド シェル と、 CGI が対象になります。

どうしても自分以外の人にSSIを使わせなければならないような場合でも、"Includes"ではなく、この"IncludesNOEXEC"オプションにしておいたほうが安全でしょう。

All〜MultiViewsを除くすべてのオプションを有効にする

"Options" ディレクティブ そのものが記述されていない場合の デフォルト の設定となります。

この "All" オプションを指定すると、"FollowSymLinks"、"Indexes"、"ExecCGI"、"Includes"の各オプションが指定されたことと同じになります。

セキュリティ を考えると、あまり好ましい設定ではありません。

None〜すべてのオプションを無効にする

タイトルのとおりです。

ただし、「 セキュリティ 第一！」とばかりに"None"オプションを設定してしまうと、当然"FollowSymLinks"オプションも無効になってしまいますから、性能上の問題が発生してしまます。従って最低でも

だけは設定しておきましょう。

Optionsの設定のルールとポイント

"Options" ディレクティブ は、 構築中のLinuxサーバー のファイルシステムの最上位である "/(ルート)" から設定する必要があります。

理由はいうまでもなく デフォルト の設定が"Options All"になっているからで、何も設定しなければファイルシステムのほぼ全域に"MultiViews"以外のオプションが有効になってしまうからです。

また、各ディレクトリに対しての"Options"設定は、上位のディレクトリに遡って最初に一致するコンテナ式ディレクティブの"Options"設定が適用されます。従って、

の場合、

"/var/www/private"→"FollowSymLinks"

"var/www/html/private"→"ExecCGI"

が各々有効になります。

上の例でお気づきかもしれませんが、注意しなければならないのは、"Options"ディレクティブの各オプションは、 個別には下位のディレクトリに引き継がれない ということです。

例えば上の例で、"/var/www/html"に"FollowSymLinks"を有効にしたい場合には、

と記述しなければなりません。

つまり、あるコンテナディレクティブに"Options"ディレクティブを記述するということは、すなわち 「上位のOptionsに関する設定を無視すること。」 と覚えてください。

上位のディレクトリに関する"Options"ディレクティブの設定を下位に引き継がせるには、

のように、"Options"ディレクティブそのものを設定しないか(この場合は完全に上位の設定を引き継ぎます)、または、"Options"ディレクティブの全てのオプションに "+" または "-" の符号を付けて記述します。

"+" はオプションの追加、 "-" はオプションの削除をそれぞれ表します。

例えば、

と設定すれば、

"var/www/html/"→"FollowSymLinks","ExecCGI"

が有効になります。

もちろん設定には、「符号なし」、「符号あり」、のどちらの方法を用いても構いませんが、「符号なし」で設定するほうが上位の設定を気にしないで済む分、間違いも少ないと思います。

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト

Order〜アクセス制御ディレクティブの順序

通常この "Order" ディレクティブ は、後に説明する "Allow" ディレクティブと、 "Deny" ディレクティブと組み合わせて使用します。

この三つを組み合わせて設定することで、設定対象への クライアント からの HTTP によるアクセスを、クライアント側の IPアドレス または FQDN を基準に許可、拒否を行うことができます。

"Order"ディレクティブの一般書式は、

Order [オプション]

です。

Deny,Allow〜拒否→許可の順で評価する

例えば、

のように記述すると、まず「アクセスを拒否する ノード 」を指定する "Deny" ディレクティブ の内容が設定され、次に「アクセスを許可するノード」を指定する "Allow" ディレクティブの内容が設定されます。

一般にこの"Deny,Allow"オプションは、

「"Deny"で広い範囲のノードにアクセス拒否を設定し、"Allow"でその中の一部分に許可を与える。」

という設定を行いたい場合に用います。

"Deny"または"Allow"ディレクティブのどちらかが省略された場合は設定されたディレクティブのみが有効になりますが、どちらも省略した場合、つまり単に

と記述すると、自動的に"Allow from all"が設定され、

「ディレクトリ"/var/www/html"に対して、全てのノードからのアクセスを許可する。」

という動作になります。

これが"Order"ディレクティブのデフォルトの設定となります。

Allow,Deny〜許可→拒否の順で評価する

例えば、

のように記述すると、まず「アクセスを許可する ノード 」を指定する "Allow" ディレクティブ の内容が設定され、次に「アクセスを拒否するノード」を指定する "Deny" ディレクティブの内容が設定されます。

一般にこの"Allow,Deny"オプションは、

「"Allow"で広い範囲のノードからのアクセスを許可し、"Deny"でその中の一部分からのアクセスを拒否する。」

という設定を行いたい場合に用います。

"Allow"または"Deny"ディレクティブのどちらかが省略された場合は設定されたディレクティブのみが有効になりますが、どちらも省略した場合、つまり単に、

と記述すると、自動的に"Deny from all"が設定され、

「ディレクトリ"/var/www/html"に対して、全てのノードからのアクセスを拒否する。」

という動作になります。

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト

Deny〜指定したノードからのアクセスを拒否

"Order" ディレクティブ を記述したコンテナの中に併記するディレクティブです。

このディレクティブに指定された ノード からの HTTP によるアクセスを拒否します。

一般書式は、

Deny from [ IPアドレス または ドメイン名 ( FQDN )]

です。

すべてのノードからのアクセスを拒否する場合は、

Deny from all

と記述します。

例えば、

と記述すると、IPアドレス"192.168.100.151"からのHTTPによるアクセスが拒否されます。

複数のノードを指定するときはスペースで区切って一行で記述します。

IPアドレスの範囲でノードを指定する場合は、 プレフィックス長 形式または サブネットマスク 形式で記述できます。

例えば、"192.168.101.0"〜"192.168.101.255"をアクセス拒否の対象にする場合は、

と記述できます。ただし上の例のように、IPアドレスの範囲が オクテット 単位で指定可能な場合は、

と、オクテットの上位だけを記述してもOKです。

また例えば、

と記述すると、"obenriclient.com"及び"*.obenriclient.com"がFQDNとして設定されているノードからのアクセスが拒否されます。

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト

Allow〜指定したノードからのアクセスを許可

"Order" ディレクティブ を記述したコンテナの中に併記するディレクティブです。

このディレクティブに指定された ノード からの HTTP によるアクセスを許可します。

一般書式は、

Allow from [ IPアドレス または ドメイン名 ( FQDN )]

です。

具体的な記述方法は、上で説明した "Deny" ディレクティブと全く同じです。

"Deny" を "Allow" 、 「拒否」 を 「許可」 に置き換えて参照してください。

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト

"Order" "Deny" "Allow"の定番設定

これらのアクセス制御 ディレクティブ は、常にセットで設定するのが一般的ですが、余程特殊な制御を行わない限り設定のパターンを決めてしまったほうが間違いは少なくなります。

実際には、以下の四つのパターンだけで済みます。

すべてのノードからのアクセスを拒否する

タイトルのとおり、何処からのアクセスも受け付けないパターンです。

ドキュメントルートよりも上位のディレクトリや、 コンテンツ の内部だけで使用するデータ類( CGI で使用するユーザーリストなど) の格納ディレクトリに設定します。

記述パターンは、

となります。

もちろん、

とすれば、"Deny" ディレクティブ の記述が不要になりますから、見た目にはすっきりとなりますが、 "Deny from All" のように具体的な動作を意味する記述があるほうが直感的に設定内容を把握しやすくなります。

すべてのノードからのアクセスを許可する

何処からでもアクセスを許可するパターンです。

ドキュメントルートに対する最も一般的な設定となります。

記述パターンは、

となります。

もちろん、

でも同じことですが、これも上の説明と同じ理由であまり好ましい設定ではありません。

一部のノードからのアクセスのみを許可する

管理用のコンテンツなどを運用するとき、ドキュメントルートの中に、自分だけがアクセスできるディレクトリを作るようなケースで用いるパターンです。

例えば、

と記述すれば、

「全ての ノード からのアクセスは拒否するが、 サブネット "192.168.100.0/24"からのアクセスは許可する。」

という設定になりますから、ディレクトリ"/var/www/html/private"は、 構築中のLinuxサーバー と同じ LAN 内の ホスト からだけアクセス可能になります。

もっと厳密に、自分専用のパソコンからのみアクセスを許可したい場合は、そのパソコンに固定のIPアドレス(例えば"192.168.100.151")を設定して、

と記述します。

また、自分の勤め先などの通信環境が、固定のIPアドレス でインターネットに接続している場合は、その WAN 側の ゲートウェイアドレス (例えば"211.183.111.34")を追記しておけば、インターネット経由でもアクセスできます。

ただ一般に、多くの人がインターネット接続を共有するような環境では、自宅の通信環境と同じく NAT + IPマスカレード で他のパソコンとWAN側ゲートウエイアドレスを共有しているのが普通ですので、厳密にいえば隣でキーボードを叩いている人からもアクセス可能だということを覚えておいてください。

一部のノードからのアクセスのみを拒否する

外部の クライアント からは自由に閲覧されても構わないが、自宅の LAN 内から見られてはまずい コンテンツ (どんなコンテンツでしょうね)を運用するような場合に有効なパターンです。

例えば、

と設定すれば、 構築中のLinuxサーバー と同じ サブネット 内の ホスト機 だけがアクセス拒否されます。

ただ、これでは自分自身も自宅内からアクセスできなくなりますので、もう一工夫してみましょう。

まず、自宅内のホスト機に割り当てる プライベートIPアドレス を、 ルーター の DHCPサーバー で"192.168.100.65"〜"192.168.100.127"の間に設定します。

そして、自分のパソコンはそれ以外の任意の IPアドレス に固定してしまいます。

そして、

と設定します。

"192.168.100.64/26"は、すなわち"192.168.100.64"〜"192.168.100.127"ですから 、同じサブネット内でもこの範囲のIPアドレスを設定されたホスト機からのアクセスのみを拒否することになるというわけです。

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト

Order Deny Allowの設定のルール

"Order" ディレクティブ は、 構築中のLinuxサーバー のファイルシステムの最上位である "/(ルート)" から設定する必要があります。

理由はいうまでもなく デフォルト の設定が"Order Deny,Allow"になっているからで、何も設定しなければファイルシステムのほぼ全域に、 HTTPによるアクセス許可が設定されてしまうからです。

また、各ディレクトリに対しての"Order"、"Deny"、"Allow"設定は、上位のディレクトリに遡って最初に一致するコンテナ式ディレクティブの設定が適用されます。従って、

の場合、例えば、

"/var/www/private"→「すべてからアクセス拒否」

"/var/www/html/guest"→「すべてからアクセス許可」

"var/www/html/private/data"→「自宅のみアクセス許可」

ということになります。

また、

のように、"Order"ディレクティブそのものが設定されていないコンテナは、そのまま上位の"Order"ディレクティブの設定を引き継ぐことになります。

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト

AllowOverride〜外部ファイルによる設定の可否

httpd は原則として主設定ファイル "/etc/httpd/conf/httpd.conf" と、 "/etc/httpd/conf.d/" 以下のモジュール用設定ファイルによって動作設定が行われます。

「 サーバー 管理者＝ コンテンツ 作成者」、 という運用形態ならばこれで何ら問題はないのですが、コンテンツ作成や運用を誰かに任せたり、コンテンツスペースを貸し出したりするような場合には不便な点があります。

それは、コンテンツ作成者から、

「何処其処のディレクトリには、こういうアクセス制限を設けて欲しい。」

とか、

「ユーザー認証でしか入れないディレクトリが必要。」

などのリクエストがあったときには、サーバー管理者が一々設定ファイルを書き換えてやらなければならないということです。

「えーい面倒くさい。自分で"httpd.conf"を書き換えてくれ。」

という訳にはいかないのは、もう説明するまでもないでしょう。

この "AllowOverride" ディレクティブ は、本来httpdの設定ファイルに記述すべき一部の設定を、コンテンツ作成者に任せてしまうためのものです。つまり 設定権利の譲渡 です。

具体的には、設定対象のディレクトリ以下の アクセスファイル に設定内容を記述することで、元の設定ファイルより優先した設定が施されるような仕組みを提供することになります。

アクセスファイルは、コンテンツスペースの中に設置することになりますから、コンテンツ作成者が自由に FTP で送信して設置できる、というわけです。

アクセスファイルの名称は、 デフォルト では ".htaccess" ですが、 "AccessFileName" ディレクティブ で設定が変更されていれば、そのファイル名です。

"AllowOverride"ディレクティブの一般書式は、

AllowOverride [オプション1] [オプション2]... です。

以下、各オプションについて説明します。

AuthConfig〜認証に関する設定を許可する

特定のディレクトリにユーザー名とパスワードによるアクセス制限をかける機能を譲渡します。詳しい内容については をご覧ください。

FileInfo〜ファイルの表示に関する設定を許可する

エラーページの指定や言語選択などの設定を譲渡します。あまり重要ではないので説明は割愛します。

Indexes〜ディレクトリ表示に関する設定を許可する

このページの前半で説明した、 "Options" ディレクティブ の "Indexes" オプションで表示される、 コンテンツ のディレクトリ表示(重要ではないので説明は割愛します)の他、重要なところでは、 "DirectoryIndex" ディレクティブ の設定などを譲渡します。

Limit〜アクセス制御に関する設定を許可する

このページで先に説明した、 "Order" 、 "Deny" 、 "Allow" の三点セットの設定を譲渡します。

Options〜動作に関する設定を許可する

このページで先に説明した、 "Options" ディレクティブの設定を譲渡します。

All〜設定可能なオプションをすべて有効にする

上で説明したすべてのオプションを全て設定します。 デフォルト の設定です。

None〜アクセスファイルを無視する

アクセスファイルの存在を完全に無視します。当然、コンテンツ作成者には何も設定権利を譲渡しません、

AllowOverrideの設定のルールとポイント

"AllowOverride" ディレクティブ が設定できるコンテナは、設定対象に 正規表現 を用いていないディレクトリ式コンテナに限定されます。

その他のコンテナでは設定しても無視されますので注意してください。

また、"AllowOverride"ディレクティブは、 構築中のLinuxサーバー のファイルシステムの最上位である "/(ルート)" から設定する必要があります。

理由はいうまでもなく デフォルト の設定が"AllowOverride All"になっているからで、何も設定しなければファイルシステムのほぼ全域でアクセスファイルが利用可能になってしまうからです。

また、各ディレクトリに対しての"AllowOverride"設定は、上位のディレクトリに遡って最初に一致するコンテナ式ディレクティブの"AllowOverride"設定が適用されます。従って、

の場合、

"/var/www/private"→アクセスファイル無視

"var/www/html/private"→アクセスファイル中の認証設定が有効

という具合に動作します。

また、

のように、"AllowOverride"ディレクティブそのものが設定されていないコンテナは、そのまま上位の"AllowOverride"ディレクティブの設定を引き継ぐことになります。

注意すべき点は、"AllowOverride"ディレクティブの各オプションは、 個別には下位のディレクトリに引き継がれない ということです。

例えば、

と設定した場合、"/var/www/html/private"以下では、"AuthConfig"オプションは有効になりません。

つまり、あるコンテナディレクティブに"AllowOverride"ディレクティブを記述するということは、すなわち 「上位のAllowOverrideに関する設定を無視すること。」 と覚えてください。

さて、説明するまでもありませんが、"AllowOverride"ディレクティブは、自分以外の第三者に httpd の設定の一部を任せる訳ですから、 セキュリティ には充分に注意してください。

しかし本当に注意すべき点はセキュリティではなく、"AllowOverride"ディレクティブは扱いを誤ると サーバー の処理に重い負担をかけてしまう可能性があるという点にあります。

ディレクトリ式コンテナに記述されている各ディレクティブは、httpdを起動するときに一度に読み込まれますが、アクセスファイルはコンテンツ作成者が設定するものであるため、設定の修正のたびにhttpdを再起動するわけにはいきません。

つまり本来httpdの起動時に読み込まれて、「最も効率的に動作できる状態」で メモリ 上に配置されるはずの設定も、アクセスファイルに記述されてしまうと 「そのディレクトリにアクセスが発生するたびに参照しなおして、コンピュータが処理できる形に翻訳しなおして．．．」 という非常に効率の悪い動作をせざるを得ないということです。

コンテンツ管理者がそのことを良く理解して、アクセスファイルの使用を必要最小限にしてくれれば良いのですが、面白がって不要な部分にまで設定したりすると、サーバーの仕事量はどんどん増えていってしまいます。

また、アクセスファイルの書式はディレクトリ式コンテナの中に記述する場合と書式は同じですが、書式を間違えたり、許可されていない設定を記述したりすると、httpdはエラー処理までやらされる羽目になります。

従って、第三者にアクセスファイルの使用を許可するときは、その人の技量とモラルを良く確かめることが大事です。

少なくとも、「ネットで知り合った」程度の知り合いに許可すべきではありません。

また、よく解説書などには 「.htaccessを利用したユーザー認証の方法」 のような解説が掲載されてますから、自分ひとりでしか使用していないhttpdに、わざわざ"AllowOverride AuthConfig"を設定して".htaccess"を設置し、悦に入っているケースがあるようです。

".htaccess"は、本来"/etc/httpd/conf/httpd.conf"に記述すべきディレクティブを、

「セキュリティの低下と、 ホスト機 の動作負荷の増大というデメリットと引き換えに、コンテンツ作成者に利便性を与えるもの。」

であって、やむを得ず使うものだということを忘れないでください。

".htaccess"は、サーバー管理者が自分のコンテンツを制御するためのものではありません。同じ設定は"/etc/httpd/conf/httpd.conf"でも可能ですし、それが「本来の姿」です。

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト