(57)【特許請求の範囲】
【請求項１】
複数のクライアントからのアクセスを受付けるホスティングシステムであって、
前記ホスティングシステムは、アパッチＨＴＴＰサーバを有し、
前記アパッチＨＴＴＰサーバはネームベースで作動するバーチャルホスト機能を有し、
アパッチＨＴＴＰサーバは所定のリソースを有し、
前記ホスティングシステムは、前記クライアントからのアクセスを受けるアクセス受付手段と、
前記アクセス受付手段が受付けたアクセスによる前記リソースの消費量を測定するリソース消費量測定手段と、
前記リソース消費量測定手段が測定したリソース消費量に応じて、利用できるリソースを制限するリソース制限手段とを含み、
前記アクセス受付手段はクライアントからのアクセスをリクエスト毎に受けるリクエスト受付手段を含み、
前記リソース消費量測定手段はリクエスト受付手段が受付けたリクエスト単位でリソース消費量を測定する、ホスティングシステム。
【請求項２】
前記リソース制限手段は、前記バーチャルホスト単位でのリソースの制限を行なう、請求項１に記載のホスティングシステム。
【請求項３】
さらにクライアントからの同時接続数を制限する同時接続数制限手段を含む、請求項１または２に記載のホスティングシステム。
【請求項４】
前記同時接続数制限手段は、ファイルまたはディレクトリに対する同時接続数を制限するファイルまたはディレクトリ同時接続数制限手段を含む、請求項３に記載のホスティングシステム。
【請求項５】
前記同時接続数制限手段は、アクセスするクライアントに対する同時接続数を制限するクライアント同時接続数制限手段を含む、請求項３または４に記載のホスティングシステム。
【請求項６】
さらに前記リソースの制限値を設定するリソース制限値設定手段を含む、請求項１〜５のいずれかに記載のホスティングシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明はホスティングシステムに関し、特に、大規模ホスティングシステムにおけるセキュリティと運用技術が改善されたホスティングシステムに関する。
【背景技術】
【０００２】
レンタルサーバのようなホスティングシステムにおいてはそのリソースを適切に管理するためにいろいろな工夫がされていた。そのような工夫の一つが、例えば、特開２００７−１８８１３９号公報（特許文献１）に開示されている。特許文献１においては、サーバクライアントシステムからなるホスティングシステムにおいて、サーバ側で利用者が選択可能なリソースを提示していた。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００７−１８８１３９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
従来のホスティングシステムにおいてリソースを適切に管理するには上記のように行なわれていた。また、このようなホスティングシステムにおいては、一般的に、運用面やセキュリティ面で実績のあるIPベースの構成をWebホスティングシステムに採用してきた。ここでのIP ベースとは、OS 上で複数のチェンジルート（以下、「chroot」）環境を構築し、各chroot 環境で別のIPアドレスを設定して各種サービスを稼働させる構成のことである。ここで、chrootとは、現在のプロセスとその子プロセス群に対してルートディレクトリを変更する操作である。ルートディレクトリを別のディレクトリに変更されたプロセスは、その範囲外のファイルにはアクセスできなくなるため、この構成では、セキュリティ面や運用の柔軟性は向上するが、IP アドレスの数やプロセスの数の増加と共に、リソース消費量も増大していくという課題があった。このように、これまではリソースよりもセキュリティの堅牢性や運用の柔軟性を優先していた。しかし、今後はクラウドや低価格ホスティング等が主流となるため、ホスティング企業としては限られたリソースで最大限のセキュリティや運用性を担保する必要がある。
【０００５】
そこで、この発明は、限られたリソースで最大限のセキュリティや運用性を担保できるホスティングシステムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
この発明に係るホスティングシステムは、複数のクライアントからのアクセスを受付けるホスティングシステムである。ホスティングシステムは、アパッチＨＴＴＰサーバを有し、アパッチＨＴＴＰサーバはネームベースで作動するバーチャルホスト機能を有し、アパッチＨＴＴＰサーバは所定のリソースを有し、ホスティングシステムは、クライアントからのアクセスを受けるアクセス受付手段と、アクセス受付手段が受付けたアクセスによるリソースの消費量を測定するリソース消費量測定手段と、リソース消費量測定手段が測定したリソース消費量に応じて、利用できるリソースを制限するリソース制限手段とを含む。
【０００７】
好ましくは、アクセス受付手段はクライアントからのアクセスをリクエスト毎に受けるリクエスト受付手段を含み、リソース消費量測定手段はリクエスト受付手段が受付けたリクエスト単位でリソース消費量を測定する。
【０００８】
さらに好ましくは、リソース制限手段は、バーチャルホスト単位でのリソースの制限を行なう。
【０００９】
さらにクライアントからの同時接続数を制限する同時接続数制限手段を含んでもよい。
【００１０】
同時接続数制限手段は、ファイルまたはディレクトリに対する同時接続数を制限するファイルまたはディレクトリ同時接続数制限手段を含んでもよいし、アクセスするクライアントに対する同時接続数を制限するクライアント同時接続数制限手段を含んでもよい。
【００１１】
さらに、リソースの制限値を設定するリソース制限値設定手段を含んでもよい。
【発明の効果】
【００１２】
この発明に係るホスティングシステムは、サーバソフトウエアとしてアパッチを使用し、アパッチが提供するネームベース機能を有するバーチャルホスト機能を利用した。ユーザからのリクエストを受けると、リクエスト単位でリソース消費量を測定し、測定したリソース消費量に応じて、利用できるリソースを制限するようにした。システムとしてネームベースを用いると共に、リソースの消費量に応じてリソースを制限するのうにしたため、限られたリソースで最大限のセキュリティや運用性を担保できるホスティングシステムを提供できる。
【図面の簡単な説明】
【００１３】
【図１】ＩＰベースとネームベースの基本構成を示すブロック図である。
【図２】この発明の一実施の形態に係るホスティングシステムを利用するレンタルサーバシステムの全体構成を示すブロック図である。
【図３】アパッチサーバの構成を示すブロック図である。
【図４】リソース消費量測定機能の設定例を示すプログラムである。
【図５】リソース消費量測定機能の設定後のログの出力例を示す図である。
【図６】ファイルおよびディレクトリに対する同時接続数チューニング設定例を示すプログラムである。
【図７】クライアントＩＰに対する同時接続数チューニング設定例を示すプログラムである。
【図８】ホスティングシステムの動作を示すフローチャートである。
【図９】ホスティングシステムの動作を示すフローチャートである。
【図１０】ホスティングシステムの動作を示すフローチャートである。
【図１１】ロードアベレージを用いたチューニング設定例を示すプログラムである。
【図１２】htaccessとＤＣＭＶＨを用いたVirtual Hostの動的設定例を示すプログラムである。
【図１３】リアルパスに解釈し直しための同時接続数チューニング設定例を示すプログラムである。
【図１４】suEXEC実行時にホスト領域でchrootする仕組みの概要を示す図である。
【発明を実施するための形態】
【００１４】
まず初めに、発明者らがこの発明にいたった考え方について説明する。Webサーバーの構成には、大きく分けてＩＰベースとネームベースがある。ＩＰベースの概要を示すブロック図を図１（Ａ）に、ネームベースの概要を示すブロック図を図１（Ｂ）に示す。
【００１５】
ＩＰベースは工夫次第で可用性の高いシステムを構築することができる。図１（Ａ）を参照して、ＩＰベースは、OSの上にchroot環境が複数設けられ、その各々にＩＰアドレスが与えられ、アパッチが作動する。すなわち、OS のシステム領域とほぼ同等の環境をOS上に作成し、その環境でchroot する。chroot 環境内部からOS のシステム領域に到達することはできないため、セキュリティ面で堅牢である。また、chroot 環境はOS のシステム領域とほぼ同等のライブラリ群を配置できるため、ソフトウェアやアプリケーションもOS とは区別された領域で独立して起動することができる。ソフトウェアの設定等もほぼ全て扱うことができるため、運用面でも可用性が高い。しかし、各chroot 環境で独立してプロセスが起動するため、リソースを多く消費する。
【００１６】
図１（Ｂ）を参照して、ネームベースでは、ＯＳの上に１つのＩＰアドレスが与えられ、その上でアパッチ（以下、「Apache」という場合がある）が作動し、1つのアパッチの上で複数のバーチャルホスト（以下、「VirtualHost」という）が作動する。したがって、リソースを最小限に抑えたシステムを構築することができる。VirtualHost では、ホスト名に対するアクセスがあった場合、Apache 内部でホスト名に対応したドキュメントルートにアクセスするように制御する。そのため、複数のホストに対して1つのApache の親プロセスが起動していればよく、IP ベースのようにホストの数だけプロセスを起動しておく必要がないため、リソースを最小限に抑えることができる。
【００１７】
しかし、VirtualHostでは各ホストで可能な設定は限られており、柔軟な設定ができない問題や、１つの親プロセスで起動しており、全てのホストが同じgid で実行されてしまうため、セキュリティ面での工夫が必要となっている。
【００１８】
ここで、uidとは、ユーザー識別子（User Identifier）であり、gidとは、ユーザーをグループに属するものとし、このグループを識別するグループ識別子（Group Identifier）である。
【００１９】
VitualHost 採用にあたり、ネームベース構成の課題を解決するための手法が世の中に数多く存在するが、どれも一長一短の手法となっている。そこで、発明者らは、これを解決するために、ホスティングシステムを次のように構成した。
【００２０】
図２は、この実施の形態におけるレンタルサーバシステム１０の全体構成を示すブロック図である。図１を参照して、レンタルサーバシステム１０は、複数のクライアント４０（図中４１〜４３で示す）と、ホスティングシステム２０と、インターネットのようなネットワーク５０とから構成されている。
【００２１】
ホスティングシステム２０は、上記したネームベースのアパッチＨＴＴＰサーバ（以下、「アパッチサーバ」という）３０で構成されている。アパッチサーバ３０は複数の任意のモジュールを接続可能である。
【００２２】
図３はこの実施の形態におけるアパッチサーバ３０に接続された機能モジュールを示す図である。ここでは、アパッチサーバ３０はクライアント４０からの同時接続数を制限する同時接続数制限モジュール３１と、プロセス情報から、プロセスが消費したリソース量を測定する処理計測モジュール３２と、クライアント４０からのリソースの使用を制限するリソース制限モジュール３３とを含む。
【００２３】
アパッチサーバ３０のVirtualHost において、プロセス情報からの高負荷対象の特定や、リソースの測定は困難とされている。そこで、発明者は、クライアント４０からApache へのリクエストがあり、処理を行ってからレスポンスを返すまでに、プロセスが消費したリソース量を測定するモジュールとして処理計測モジュール３２を開発した。このモジュールによって、指定したリソース量を超えた場合に、リクエストのあったファイル名、ホスト名、システムCPU 使用時間、ユーザーCPU 使用時間、メモリ使用量を計測しロギングできる。指定できるリソース量は、システムCPU 時間、ユーザーCPU 時間、メモリ使用量となっている。このモジュールによって、レンタルサーバシステム１０の運用者はVirual  Host 等を気にすることなく、高負荷ホストやスクリプトを早期に調査、検知し適切にチューニングすることができる。図４にリソース消費量測定機能の設定例を示すプログラム、図５に設定後のログの出力例を示す。
【００２４】
次に、同時接続数制限モジュールについて説明する。従来のVirtualHost 単位でのチューニング機能はあまり充実していない。たとえば、VirtualHost 毎に同時接続可能なクライアント４０の数（MaxClinets ）を設定できない等が挙げられる。そこで、発明者は、ホストやディレクトリ単位、又はスクリプト等のファイル単位で同時接続数を制限できる機能としてこのモジュールを実装した。このモジュールを用いて的確に負荷対象のみをチューニングする方法について以下に説明する。
【００２５】
同時接続数制限モジュール３１は、ファイル及びディレクトリに対する同時接続数チューニングモジュールとクライアントＩＰに対する同時接続数チューニングモジュールとを含む。まず、ファイル及びディレクトリに対する同時接続数チューニングモジュールについて説明する。
【００２６】
人気サイトでは、しばしば同一スクリプトやメディア、ホストに対して、複数のクライアントから同時に大量のアクセスが発生する。その結果、高負荷となってサーバーのレスポンスが大きく低下し、場合によってはサーバーダウンとなる。そこで、高負荷ホスト全体や高負荷スクリプトへのアクセスをチューニングするために、リクエスト対象への同時接続数をチューニングする機能を実装した。設定対象は、任意のホストやファイル名、ファイルへのフルパス、任意のディレクトリ、正規表現にマッチしたファイルやフォルダ等であり、同時接続数１からの設定が可能である。同時接続数の設定値を超えた場合は、リターンコード503（Service Unavailable）をクライアント４０に返す。図６にファイル及びディレクトリに対する同時接続数のチューニング設定例を示す。設定したディレクトリやファイルにアクセスがあった場合、チューニング値の数しか全クライアント４０から同時にアクセスできない。例えば、チューニング値を１にしていた場合は、ＩＰアドレスが172。16。0。1 と192。168。0。2 から同時（厳密には172。16。0。1 のリクエスト処理中に192。168。0。2 からリクエストが発生)にアクセスがあった場合、172。16。0。1 のリクエスト処理中は192。168。0。2 のリクエストに対してリクエスト処理を行わず503 を返す。
【００２７】
次に、クライアントＩＰに対する同時接続数チューニングモジュールについて説明する。動画サイトやファイルダウンロードサイトでは、同一IP から様々ファイルに対して並行してダウンロードするような使い方が多く、トラフィックやサーバー負荷を高める原因となる。そこで、クライアントIP から指定のディレクトリやホスト、ファイルに対して同一IP からアクセスがあった場合は、同一IP からの同時接続数をチューニングする機能を実装した。この機能により、同一IP から並行した大量のファイルダウンロードを調整することができる。設定対象は、任意のホストやファイル、ファイルへのフルパス、任意のディレクトリ、正規表現にマッチしたファイルやフォルダ等であり、同時接続数1 からの設定が可能である。同時接続数の設定値を超えた場合は、リターンコード503を返す。
【００２８】
同様のモジュールとしては、mod_limitipconnやmod_cbandが存在するが、いずれもディレクトリ単位やファイル単位での正確なチューニングができないため採用していない。図７にファイルやディレクトリに対する、クライアントIP 単位の同時接続数をチューニングする場合の設定例を示す。設定したディレクトリやファイルにアクセスがあった場合、アクセス元のクライアントがそれぞれチューニング設定値の数しか同時にアクセスできない。例えば、チューニング値を１にしていた場合は、設定ディレクトリに対して172。16。0。1 と192。168。0。2 から同時（厳密には172。16。0。1 のリクエスト処理中に192。168。0。2 からリクエストが発生し、さらに172。16。0。1 からリクエストが発生)にアクセスがあった場合、172。16。0。1 のリクエスト処理中は172。16。0。1 からのもう1 つのリクエストに対してはリクエスト処理を行わず503 を返し、192。168。0。2 のリクエストに対しては正常に処理を行う。
【００２９】
次に、リソース制限モジュール３３について説明する。リソース制限モジュール３３は、ApacheをインストールしているOS自体の負荷をあらわすロードアベレージという値をOSから取得する。ロードアベレージの値は負荷が高いほど高くなる。そのため、あるロードアベレージの値を閾値に設定し、その値以上になった場合は、Apacheがクライアントにリターンコード503を返す。このようにしてリソース制限を行なう。
【００３０】
次に、アパッチサーバ３０のＣＰＵが行なう動作について説明する。図８〜図１０はアパッチサーバ３０のＣＰＵがクライアント４０からのリクエストを受付てからそのレスポンスの完了までの処理を示すフローチャートである。図８〜図１０を参照してこの処理について説明する。
【００３１】
クライアント４０からホスティングシステム２０にリクエストが開始されると、ホスティングシステム２０はクライアント４０からのアクセス（リクエスト）を受付ける（ステップＳ１１、以下、ステップを省略する）。動的設定を取得し（Ｓ１２）、クライアントＩＰの同時接続数制限が存在するか否か、アクセスコンテンツの同時接続数制限が存在するか否か、システムリソース制限値が存在するか否かを判断する（Ｓ１３〜Ｓ１５）。これらのいずれかが存在すれば、アクセスコンテンツのパスからリアルパスを解析し（Ｓ１６）、設定対象のコンテンツか否かを判断する（Ｓ１７）。ここで、設定対象のコンテンツか否かはホスト、ディレクトリ、ファイル単位で行なわれる。
【００３２】
一方、これらの制限が存在しなければ（Ｓ１３〜Ｓ１５でＮＯ）、リクエストの処理を開始する（Ｓ１８）。
【００３３】
リクエストコンテンツ領域(Virtual Host領域)でchrootし（Ｓ２３）、リクエストコンテンツのuid、gidのセキュリティをチェックし（Ｓ２４）、コンテンツ処理を行ない（Ｓ２５）、リクエストコンテンツ領域からchrootを抜ける（Ｓ２６）。
【００３４】
処理計測機能が有効か否かを判断し（Ｓ２７）、有効であれば（Ｓ２７でＹＥＳ）、アクセスファイルやアクセスホスト情報とともにリソース結果をログに出力して（Ｓ２８）、コンテンツ処理結果をクライアント４０に返し（Ｓ２９）、処理を終了する（Ｓ３２）。処理計測機能が有効でなければ（Ｓ２７でＮＯ）、Ｓ２９へ移動して処理を終了する（Ｓ３２）。
【００３５】
一方、Ｓ１７で設定対象のコンテンツであれば（Ｓ１７でＹＥＳ）、設定閾値を越えているか否かが判断される（Ｓ１９）。Ｓ１７で設定対象のコンテンツでなかったり（Ｓ１７でＮＯ）、Ｓ１９で設定閾値を越えていないと判断されたときは（Ｓ１９でＮＯ）、Ｓ１８へ移動してリクエストの処理を開始する。
【００３６】
Ｓ１９で設定閾値を超えていれば（Ｓ１９でＹＥＳ）、高負荷のためアクセスできない旨をクライアント４０に返し（Ｓ３１）、処理を終了する（Ｓ３２）。
【００３７】
以上のように、アパッチサーバ３０のＣＰＵは、クライアントからのアクセスを受けるアクセス受付手段と、アクセス受付手段が受付けたアクセスによるリソースの消費量を測定するリソース消費量測定手段と、リソース消費量測定手段が測定したリソース消費量に応じて、利用できるリソースを制限するリソース制限手段と、クライアントからの同時接続数を制限する同時接続数制限手段と、ファイルまたはディレクトリに対する同時接続数を制限するファイルまたはディレクトリ同時接続数制限手段と、アクセスするクライアントに対する同時接続数を制限するクライアント同時接続数制限手段として作動する。
【００３８】
次に、リソース変化に対応したチューニング機能について説明する。これは、図８のＳ１５に該当する。この機能は、リソース変化に対応したチューニングを容易にするための新たなアプローチである。Virtual Host は、Apache の親プロセス一つで起動している。そのため、なんらかの原因で親プロセスが停止した場合は、全てのホストが停止することになる。最も多い原因として、サーバー高負荷によるプロセス停止が挙げられる。そこで、常にサーバーのリソース変化に対応したチューニングが必要となる。Apache のデフォルトの設定としては、メモリやプロセス数等のチューニングがあるが、CPUのチューニングは限られている。NAS やSAN によるストレージの統合化に伴いCPU 使用量、特にファイルシステムとのI/O が大量に発生して高負荷になる場合が多い。なお、これは、複数のサーバのデータ領域を、ストレージに統一し、サーバ間で同様のデータを共有する手法である。そのため、ストレージには複数のサーバからデータの読み込みや書き込みが発生し、負荷がかかる。
【００３９】
CPU 周りのチューニングとしては、RlimitCPU があるが、これは指定してCPU 使用時間を超過した場合、Apache の処理ではなくKernel のulimit の機能で処理が強制的に切断されるため、契約等が発生するようなサイトにおいては信頼性が低くなる。
【００４０】
そこで、CPU 処理やI/O 処理の負荷の目安となるロードアベレージの数値に着目し、ロードアベレージの数値によってレスポンスを返すかどうかをApache が判断する機能を実装した。ロードアベレージの数値を閾値として設定し、その数値を超えた場合はリターンコード503 を返すことで安全に処理を中断させる。ロードアベレージを用いたチューニングは、任意のファイル、ファイルへのフルパス、任意のディレクトリ、正規表現にマッチしたファイルやフォルダを対象に、1分平均の数値を閾値に設定できる。図１１にファイルやディレクトリに対して、ロードアベレージを用いたチューニングの設定例を示す。この場合、指定したディレクトリやファイルにアクセスがあり、かつシステムのロードアベレージがチューニング値を超えていた場合は、リクエスト処理を行わず５０３を返す。
【００４１】
次に、Apache をリスタートせずに新規ホストを追加するための新たなアプローチについて説明する。新規ホスト納品時にはApache に設定を追加するため、リスタートが必要となる。しかし、VirtualHost はApache のリスタートによって全てのホストが一時的に停止するという課題がある。
【００４２】
そこで、できる限りApache のリスタートを実施しないようにするため、Apache にはDynamicallyConfigured Mass Virtual Hosting（以降DCMVH とする）という設定記述方法がある。本来、ホスト追加時には新規ホスト用のVirtualHost 設定を記述する。しかし、VirtualHost の設定はホスト名やドキュメントルート名等が異なるだけで、その他の設定は同じ場合が多い。そこで、DCMVH の設定記述法を利用すると、ドキュメントルートにホスト名を含んだパスになるようにディレクトリを作成しておけば、VirtualHost の設定においてパスのホスト名部分を変数で記述することができる。その記述によって、アクセスのあったホスト名で設定を動的に読み替え、該当のドキュメントルートにアクセスできるようになる。
【００４３】
しかし、suEXEC の設定はVirtualHost ごとにユーザー名とグループ名を指定する必要があり、DCMVH を用いてそれらを動的に設定することができない。そこで、suEXEC のユーザー名とグループ名をダミーとして設定し、suEXEC 内部でユーザー名とグループ名を解釈するようにsuEXEC を改修した。これについては後述する。この改修とDCMVH によって、全てのVirtualHost の設定を一つの設定に書き直すことができる。また、htaccess と同じ機能をもったホスト専用のチューニングファイルを用意した。図１２は、htaccess とDCMVH を用いたVirtualHost の動的設定例を示す図である。
【００４４】
また、上記したApache モジュールは。htaccess に記述することでApache のリスタート無く新たな設定を反映させることができる。以上の動的設定により、運用や新規ホスト追加等の場合に新規設定を追加せず、図１２の記述のみでApache のリスタート無く反映させることができる。
【００４５】
次に、この実施の形態に係るホスティングシステムにおいて新たに開発した、シンボリックリンクを含むパスをリアルパスに解釈し直す機能について説明する。マルチドメインサービス等では、複数のホスト名を同じドキュメントルートに紐づける必要がある。上記した動的設定を導入した場合は、ホスト名を表すディレクトリ名に対して、別のホスト名のシンボリックリンクを張ることで簡単にこのサービスを実現することができる。
【００４６】
なお、マルチドメインサービスとはWebホスティングにおいて、あるドメインにアクセスした場合と、別のドメインにアクセスがあった場合に、どちらのドメインも同じドキュメントルートにアクセスできるようにするサービスのことである。
【００４７】
上記のようにして実装したモジュールでチューニングを行う場合、任意のスクリプトに対するフルパスを指定することがある。Apache は仕様上、解釈するフルパスがシンボリックリンクを含んでいた場合、リアルパスに解釈し直さない。
【００４８】
この設定によって、hoge.com やfuga.jp 経由でcpu.cgi にアクセスがあった場合、両方のホストにチューニング設定が適応される。Files ディレクティブは記述していなくても良いが、記述していた方がcpu.cgi ファイルにマッチした場合でしかディレクティブ内の処理を行わないので、パフォーマンスが上がる。
【００４９】
次に、このホスティングシステム２０において新たに採用したセキュリティ面の課題解決方法について説明する。セキュリティ問題の課題として、システム領域の覗き見、CGI 版PHP の利用に関する課題、suEXECの個別設定がある。それらの問題を解決するために、suEXEC を改修した。
【００５０】
通常、ApacheにおいてCGIプログラムなどは、コンテンツのユーザーとは関係なく、すべて同じApacheの実行ユーザー（デフォルトではnobody）の権限で実行される。例えば、CGIプログラムからアクセスされるデータファイルはnobodyがアクセスできるような権限設定がされていなければならない。しかし、このような権限設定がされたファイルは、CGIを経由してすべてのユーザーによってアクセス可能になってしまう。つまり、別のユーザーによってファイルを閲覧されたり、破壊されたりする恐れがある。そこで、suEXECは、CGIプログラムなどをApacheの実行ユーザー権限ではなく、それぞれのコンテンツユーザーの権限で実行するためのApacheのモジュールである。
【００５１】
具体的には、suEXEC 時にホスト領域でchroot する機能実装システム領域や他ホスト領域を覗き見できないように、suEXEC 時に各ホスト環境でchroot してからスクリプトを実行するような改修を行った。図１４はsuEXEC 内部でchroot する仕組みの概要図である。これにより、CGI やPHP はホスト領域内の隔離された領域で実行されるため、ホスト領域より外のファイルを閲覧することができない。そのため、システム領域や他ホスト領域へもアクセスできない。
【００５２】
次に、新たな機能として、php ファイルはsuEXEC 内部でphp-cgi に直接渡して実行する機能について説明する。これは、PHP のシェバン行やパーミッション設定をホスト管理者に強制しないようにするための新たなアプローチである。suEXEC を採用するためには、CGI 版のPerl とPHP を使用する必要がある。
【００５３】
この場合、CGI 版PHP においては、シェバン行とパーミッション設定をホスト管理者に強制しなければならない課題があった。その課題を解決するため、suEXEC 内で。php ファイルはphp-cgi に直接渡して実行するように改修した。これによって、php のシェバン行や実行権限の有無をホスト管理者が意識することなく、CGI 版PHP をsuEXEC 環境で実行できる。複雑なモジュールやラッパー等を組み込む必要がないという点で非常にシンプルな構成になっている。
【００５４】
次に、新たな機能として、ホスト単位でのSuexecUserGroup 設定をsuEXEC バイナリ内部で解釈する機能について説明する。これは、suEXEC 採用によるホスト毎の個別設定を無くすようにするための新たなアプローチである。上記した動的設定において、VirtualHost の設定はほとんどが変数で置き換えることができる。しかし、suEXEC を採用した場合は、ホスト単位でユーザー名とグループ名をSuexecUserGroup パラメータに設定する必要がある。これらのパラメータはDynamically Configured Mass Virtual Hosting では対応できない。そこで、suEXEC の改修によって、ホスト毎のSuexecUserGroupパラメータに記述するユーザー名とグループ名は全て同一のダミー名を設定し、実行ファイルが存在するディレクトリのuid とgid にsuEXEC 内部で読み替えるようにした。また、読み替えの際には、rootのuid とgid であった場合、実行対象のプログラムと実行対象のプログラムが存在するディレクトリとドキュメントルートディレクトリのuid とgid が1つでも異なっていた場合はエラーを返すように実装した。
【００５５】
なお、上記実施の形態においては、開発した複数の新たな機能モジュールをアパッチサーバに組み込む場合について説明したが、このうちの任意の機能モジュールのみを実装するようにしてもよい。
【００５６】
以上、図面を参照してこの発明の実施形態を説明したが、この発明は、図示した実施形態のものに限定されない。図示された実施形態に対して、この発明と同一の範囲内において、あるいは均等の範囲内において、種々の修正や変形を加えることが可能である。
【産業上の利用可能性】
【００５７】
この発明に係るホスティングシステムは、限られたリソースで最大限のセキュリティや運用性を担保できるホスティングシステムを提供できるため、ホスティングシステムとして有利に利用される。
【符号の説明】
【００５８】
１０  レンタルサーバシステム、２０  ホスティングシステム、３０  アパッチサーバ、３１  同時接続数制限モジュール、３２  処理計測モジュール、３３  リソース制限モジュール３３、４０  クライアント５０  ネットワーク。
【図１】
0005604390.tif 000002
【図２】
0005604390.tif 000003
【図３】
0005604390.tif 000004
【図４】
0005604390.tif 000005
【図５】
0005604390.tif 000006
【図６】
0005604390.tif 000007
【図７】
0005604390.tif 000008
【図８】
0005604390.tif 000009
【図９】
0005604390.tif 000010
【図１０】
0005604390.tif 000011
【図１１】
0005604390.tif 000012
【図１２】
0005604390.tif 000013
【図１３】
0005604390.tif 000014
【図１４】
0005604390.tif 000015