JP5056529B2 - アクセス制御プログラム - Google Patents

Description

この発明は、利用者端末とＣＩＦＳまたはＮＦＳで接続され、利用者端末からファイルシステムへのアクセス要求を受信して、当該アクセス要求を許可するか否かを判定するアクセス制御プログラムに関する。

従来より、膨大な電子データを生産する情報社会において、多種多様なクライアントに対してこのような電子データを共有させるＮＡＳ（Network Attached Storage）などのファイルサーバが、重要な技術となっている。

また、多種多様なクライアントがＮＡＳへアクセスするために利用するファイルアクセスプロトコルとしては、ＵＮＩＸ（登録商標）系クライアント用のＮＦＳ（Network File System）と、Ｗｉｎｄｏｗｓ（登録商標）系クライアント用のＣＩＦＳ（Common Internet File System）の二種類が主流となっている。

そして、ＮＦＳを利用するクライアントと、ＣＩＦＳを利用するクライアントとの両方のクライアントが存在する環境においてファイルサーバを導入する場合、プロトコルによって利用できるアクセス権限の内容（アクセス制御）が異なるため、それぞれのプロトコルに対応した別々のファイルサーバを導入する必要があり、コストの拡大に繋がっていた。そこで、ＮＦＳとＣＩＦＳとの両方のプロトコルに対応できるファイルサーバを開発する様々な技術が開示されている。

例えば、特許文献１では、従来のＵＮＩＸ（登録商標）サーバやＷｉｎｄｏｗｓ（登録商標）サーバなどのソフトウエア資産にとらわれず、新しくファイルサーバを開発する技術が開示されている。この開示された技術では、ＣＩＦＳを利用するクライアントに対して正しいアクセス制御を実施している。

また、ＧＰＬ（General Public License）のソフトウエアであるＳａｍｂａを用いた技術としては、元来ＮＦＳプロトコルのみ対応するＵＮＩＸ(登録商標)系のＯＳ（Operating System）を用いて、ＣＩＦＳに対応したファイルサーバを開発する技術がある（非特許文献１参照）。具体的には、Ｓａｍｂａは、ＮＦＳを利用するクライアントとＣＩＦＳを利用するクライアントとの両方のクライアントに対して、標準的なＵＮＩＸ（登録商標）またはＰＯＳＩＸ−ＡＣＬ（Portable Operating System Interface for UNIX（登録商標）−Access Control List）に備わっている基本権限「参照権、更新権、実行権」に基づいてアクセス制御を実施する。

米国特許第６，４５７，１３０号明細書 "Ｓａｍｂａ２．２詳細〜Ｗｉｎｄｏｗｓ（登録商標）ＮＴ／２０００との機能比較"、日本Ｓａｍｂａユーザ会、［online］、［平成１９年２月２１日検索］、インターネット＜http://www1.samba.gr.jp/doc/func_2.2.html＞

しかしながら、上記した従来の技術である特許文献１では、ファイルサーバを開発するまでに非常に多くの工数がかかるという課題があった。具体的には、既存のＵＮＩＸ（登録商標）サーバとＷｉｎｄｏｗｓ（登録商標）サーバとの両方の機能およびアクセス制御を一つのファイルサーバ内に開発する必要があるので、ファイルサーバを開発するのに非常に多くの工数がかかる。

また、上記した従来の技術である非特許文献１では、正確なアクセス制御を実現できないという課題があった。具体的には、ＣＩＦＳを用いるＷｉｎｄｏｗｓ（登録商標）系のアクセス権限には、標準的なＵＮＩＸ（登録商標）またはＰＯＳＩＸ−ＡＣＬに備わっている基本権限「参照権、更新権、実行権」に加え「属性更新権、サブディレクトリ作成権」などの細かな権限が存在する。そのため、非特許文献１では、これらの細かな権限を持つＣＩＦＳ（Ｗｉｎｄｏｗｓ（登録商標）系）のアクセス制御を、基本権限のみを持つＮＦＳ（ＵＮＩＸ（登録商標）系）のアクセス権限に対応付けることでアクセス制御を実現しているので、正確性に欠けることとなり、Ｗｉｎｄｏｗｓ（登録商標）系のアクセス権限を正確に制御することができない。

そこで、この発明は、上述した従来技術の課題を解決するためになされたものであり、正確なアクセス制御を備えたファイルサーバを、従来技術に比べ少ない工数で開発することが可能となるアクセス制御プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するため、本発明は、利用者端末とＣＩＦＳまたはＮＦＳで接続され、前記利用者端末からファイルシステムへのアクセス要求を受信して、当該アクセス要求を許可するか否かを判定することをコンピュータに実行させるアクセス制御プログラムであって、前記ファイルシステムの各オブジェクトに対してアクセス要求を許可するか拒否するかを示すアクセス制御情報を記憶するアクセス制御情報記憶手段と、前記ＮＦＳで使用されるアクセス要求の基本権限であって、前記ＣＩＦＳで接続される利用者端末から受け付けたアクセス要求に対して対応付けられた前記基本権限が許可されているか否かを、前記アクセス制御情報記憶手段に記憶されるアクセス制御情報それぞれに対して前記基本権限を対応付けたアクセス制御情報を参照して判定する第一のアクセス制御手順と、前記第一のアクセス制御手順により許可された基本権限の元のアクセス要求に対して、前記アクセス制御情報記憶手段に記憶されるアクセス制御情報を参照し、当該アクセス要求を許可するか否かを判定する第二のアクセス制御手順と、をコンピュータに実行させることを特徴とする。

また、本発明は、上記の発明において前記第一のアクセス制御手順は、前記ＣＩＦＳで接続される利用者端末から受け付けたアクセス要求に対して対応付けられた基本権限が、前記基本権限に対応付けたアクセス制御情報の一つ以上の構成要素に許可されていた場合に、当該基本権限を許可すると判定し、全ての構成要素に拒否されていた場合に、当該基本権限を拒否すると判定することを特徴とする。

また、本発明は、上記の発明において、前記アクセス制御情報記憶手段は、前記ファイルシステム上の各オブジェクトに関する情報を記憶するｉｎｏｄｅの拡張属性領域に、前記アクセス制御情報を記憶することを特徴とする。

また、本発明は、利用者端末とＣＩＦＳまたはＮＦＳで接続され、前記利用者端末からファイルシステムへのアクセス要求を受信して、当該アクセス要求を許可するか否かを判定することをコンピュータに実行させるアクセス制御プログラムであって、前記ＣＩＦＳで接続される利用者端末からファイル作成要求を受け付けた場合に、当該ファイル作成要求に応答してファイル作成を行うシステムコールを発行する前に、前記ファイルシステムの各オブジェクトに対してアクセス要求を許可するか拒否するかを示す当該ファイル用のアクセス制御情報を、当該システムコールとは異なるＩＯコントロールを介して発行するアクセス制御情報発行手順と、前記アクセス制御情報発行手順によりＩＯコントロールを介して発行されたアクセス制御情報を、前記ファイルシステム上のｉｎｏｄｅの拡張属性領域に格納する格納処理を実行するのに際して、前記ファイルシステムで実施される各メタデータ更新処理のための各ジャーナルと同一ジャーナルセッションで括って、前記格納処理を実行する格納処理手順と、前記ＣＩＦＳで接続される利用者端末からアクセス要求を受け付けた場合に、前記格納処理手順によってファイルシステムに格納されたアクセス制御情報に基づいて、当該アクセス要求を許可するか否かを判定するアクセス制御手順と、をコンピュータに実行させることを特徴とする。

また、本発明は、上記の発明において、前記ＣＩＦＳで接続される利用者端末からアクセスされるファイルシステムのボリュームに関して、前記ファイルシステムのルートディレクトリおよびメタデータに関するインターフェースをフックし、当該マウント先のディレクトリに関するインターフェースをフックするのに際して、当該ディレクトリ直下のファイルに関するインターフェースをフックすることで、前記マウントされたボリュームに関するファイルシステムインターフェースを過不足なくフックするフック制御手順をさらにコンピュータに実行させることを特徴とする。

また、本発明は、上記の発明において、前記フック制御手順は、前記ＣＩＦＳで接続される利用者端末からアクセスされるファイルシステムのボリュームに関して、当該ボリュームをマウントするマウント要求に含まれるマウントオプションにフック対象であることを示す識別子が付加されている場合にのみ、当該ボリュームがフック対象であると判定することを特徴とする。

また、本発明は、上記の発明において、前記フック制御手順は、フック中のボリューム数をフックドライバ内部でカウントし、このカウントが残るうちは、ドライバのアンロードを禁止することを特徴とする。

また、本発明は、上記の発明において、前記格納処理手順は、前記アクセス制御情報をファイルシステム上のｉｎｏｄｅの拡張属性領域に格納する場合に、前記ＩＯコントロールにおいて、当該アクセス制御情報と共にコンテキストをカーネル内フックドライバに一時的に格納し、前記システムコールにおいて、当該コンテキストが一致しているかを判定し、当該アクセス制御情報が前記アクセス制御情報受付手順により受け付けられた正当なアクセス制御情報であることを条件として、前記拡張属性領域に格納することを特徴とする。

本発明によれば、ファイルシステムの各オブジェクトに対してアクセス要求を許可するか拒否するかを示すアクセス制御情報を記憶し、ＮＦＳで使用されるアクセス要求の基本権限であって、ＣＩＦＳで接続される利用者端末から受け付けたアクセス要求に対して対応付けられた基本権限が許可されているか否かを、記憶されるアクセス制御情報それぞれに対して基本権限を対応付けたアクセス制御情報を参照して判定し、許可された基本権限の元のアクセス要求に対して、記憶されるアクセス制御情報を参照し、当該アクセス要求を許可するか否かを判定するので、正確なアクセス制御を備えたファイルサーバを、従来技術に比べ少ない工数で開発することが可能である。

例えば、ＵＮＩＸ（登録商標）系システムの従来からの内部インターフェース仕様の都合で、アクセス要求を「参照権、更新権、実行権」の三種類でしかチェックすることができないが、Ｗｉｎｄｏｗｓ（登録商標）系のＣＩＦＳで接続される利用者端末から受信したＵＮＩＸ（登録商標）系のアクセス要求をさらに詳細に分類されたアクセス要求に対しても、一度、ＵＮＩＸ（登録商標）系のアクセス要求に変換し、その後、詳細なアクセス要求を判定することができる結果、ＵＮＩＸ（登録商標）系のアクセス要求に強引に対応付けたまま処理する必要がなく、詳細なアクセス要求のまま処理することができるので、正確なアクセス制御を実現することが可能である。

また、Ｗｉｎｄｏｗｓ（登録商標）やＵＮＩＸ（登録商標）に依存することのない独自のファイルサーバを開発する必要がなく、ＵＮＩＸ（登録商標）系のＯＳを利用してファイルサーバを開発して、両方の利用者端末からのアクセスを制御することができる結果、開発までに要する工数を短縮することが可能である。

また、本発明によれば、ＣＩＦＳで接続される利用者端末から受け付けたアクセス要求に対して対応付けられた基本権限が、基本権限に対応付けたアクセス制御情報の一つ以上の構成要素に許可されていた場合に、当該基本権限を許可すると判定し、全ての構成要素に拒否されていた場合に、当該基本権限を拒否すると判定するので、はじめにアクセス要求を甘めに制御し、次に詳細にアクセス制御することができる結果、より正確なアクセス制御を実現することが可能である。

例えば、ＵＮＩＸ（登録商標）系システムの従来からの内部インターフェース仕様の都合で、アクセス要求を「参照権、更新権、実行権」の三種類でしかチェックすることができないため、Ｗｉｎｄｏｗｓ（登録商標）系のＣＩＦＳで接続される利用者端末から受信した詳細に分類されたアクセス要求をＵＮＩＸ（登録商標）系に置き換えて、第一のアクセス制御手段で厳しく、強引に判定すると、本当なら許可されるべきであった詳細なアクセス要求を拒否することになる恐れがある。そこで、はじめにアクセス要求を甘めに制御し、次に詳細にアクセス制御することで、このような誤判定を防止することができる結果、より正確なアクセス制御を実現することが可能である。

また、本発明によれば、ファイルシステム上の各オブジェクトに関する情報を記憶するｉｎｏｄｅの拡張属性領域に、アクセス制御情報を記憶し、その拡張領域として、データフォーマットがあらかじめ定まっているＰＯＳＩＸ−ＡＣＬ／ＬＩＤＳ・ＳＥＬＩＮＵＸなどを使用せず、ＵＳＥＲ領域を使用することで、任意のデータフォーマットを使用することができるので、ファイルシステムやＶＦＳの修正を最小限に留めることが可能である。

また、本発明によれば、ＣＩＦＳで接続される利用者端末からファイル作成要求を受け付けた場合に、当該ファイル作成要求に応答してファイル作成を行うシステムコールを発行する前に、ファイルシステムの各オブジェクトに対してアクセス要求を許可するか拒否するかを示す当該ファイル用のアクセス制御情報を、当該システムコールとは異なるＩＯコントロールを介して発行し、ＩＯコントロールを介して発行されたアクセス制御情報を、ファイルシステム上のｉｎｏｄｅの拡張属性領域に格納する格納処理を実行するのに際して、ファイルシステムで実施される各メタデータ更新処理のための各ジャーナルと同一ジャーナルセッションで括って、格納処理を実行し、ＣＩＦＳで接続される利用者端末からアクセス要求を受け付けた場合に、ファイルシステムに格納されたアクセス制御情報に基づいて、当該アクセス要求を許可するか否かを判定するので、アトミック性が保証されたアクセス制御情報を用いてアクセス制御を実施することができる結果、ＵＮＩＸ（登録商標）系のアクセス要求に強引に対応付けたまま処理する必要がなく、詳細なアクセス要求のまま処理することができるので、より正確なアクセス制御を実現することが可能である。

また、本発明によれば、ＣＩＦＳで接続される利用者端末からアクセスされるファイルシステムのボリュームに関してファイルシステムのルートディレクトリおよびメタデータに関するインターフェースをフックし、当該マウント先のディレクトリに関するインターフェースをフックするのに際して、当該ディレクトリ直下のファイルに関するインターフェースをフックすることで、前記マウントされたボリュームに関するファイルシステムインターフェースを過不足なくフックするので、インターフェース関数ベクターを改ざんするのではなく、そのポインタ元（スーパーブロックやinode）のポインタを改ざん版インターフェース関数ベクターへリダイレクトすることができる結果、ボリューム限定のフック設定を実現すると共に、フック対象外ボリュームとのフック設定処理に関する排他制御を不要化することが可能である。

また、本発明によれば、ＣＩＦＳで接続される利用者端末からアクセスされるファイルシステムのボリュームに関して当該ボリュームをマウントするマウント要求に含まれるマウントオプションにフック対象であることを示す識別子が付加されている場合にのみ、当該ボリュームがフック対象であると判定するので、無関係なボリュームに関するフックの設定を回避することが可能である。

また、本発明によれば、フック中のボリューム数をフックドライバ内部でカウントし、このカウントが残るうちは、ドライバのアンロードを禁止するので、フックの中途離脱（FSインターフェースのリダイレクト先の消滅によるパニック停止）を防止することが可能である。

また、本発明によれば、アクセス制御情報をファイルシステム上のｉｎｏｄｅの拡張属性領域に格納する場合に、ＩＯコントロールにおいて、当該アクセス制御情報と共にコンテキストをカーネル内フックドライバに一時的に格納し、システムコールにおいて、当該コンテキストが一致しているかを判定し、当該アクセス制御情報が受け付けられた正当なアクセス制御情報であることを条件として、拡張属性領域に格納するので、ＩＯコントロールとシステムコールの関連を適切に判断することが可能である。

以下に添付図面を参照して、この発明に係るアクセス制御プログラムの実施例を詳細に説明する。なお、以下では、本実施例で用いる主要な用語、本実施例に係るファイルサーバの概要および特徴、ファイルサーバの構成および処理の流れを順に説明し、最後に本実施例に対する種々の変形例を説明する。

本実施例で用いる「ファイルサーバ（特許請求の範囲に記載の「アクセス制御プログラム」に対応する。）」とは、自装置が管理しているデータベースなどをＬＡＮ（Local Area Network）やＷＡＮ（Wide Area Network）などのネットワーク上の他のコンピュータ装置と共有し、外部からでも当該データベースを利用できるようにするコンピュータ装置であり、例えば、ＮＡＳ（Network Attached Storage）などがこれに該当する。

「ファイルサーバ」上にファイルを配置することで、ファイルサーバに接続されるコンピュータが自由にファイルを閲覧したり更新したりする操作を行うことができ、以前まで行われていたコンピュータ間でのファイルの移動や更新管理などの煩雑な作業を解消することができ、データ（ファイル）の管理が飛躍的に容易になる。

また、ファイルサーバを利用する利用者端末としては、Ｗｉｎｄｏｗｓ（登録商標）系のＣＩＦＳ（Common Internet File System）を利用して接続する端末や、ＵＮＩＸ（登録商標）系のＮＦＳ（Network File System）を利用して接続する端末などがある。ＣＩＦＳやＮＦＳは、ファイルサーバを利用するためのプロトコルであり、これらのプロトコル間では、指定できるアクセス権限が異なる。具体的には、ＣＩＦＳを利用する場合、ＮＦＳに比べてより細かなアクセス権限の制御が可能である。

そのため、これらのプロトコルが混在する環境で「ファイルサーバ」を利用するために、ＣＩＦＳのアクセス権限にＮＦＳのアクセス権限を当てはめることで、両方のクライアントからのアクセスを制御していた。ところが、ＣＩＦＳのアクセス権限にＮＦＳのアクセス権限を当てはめることとは、つまり、ＣＩＦＳの細かなアクセス権限を無理やりＮＦＳのアクセス権限で制御することとなり、ＣＩＦＳのアクセス権限を正確に制御できていない。具体的には、ファイルサーバは、ＣＩＦＳのアクセス権限をＮＦＳのアクセス権限の基本権限である「ＲＥＡＤ、ＷＲＩＴＥ、ＥＸＥＣ」の三種類に当てはめて制御する必要があった。

このようなことから、ＣＩＦＳならば「アクセス拒否」となるはずのアクセス要求が、「アクセス許可」と制御されるような事象が起こっていた。そのため、これらのプロトコルが混在する環境で「ファイルサーバ」を利用する場合に、ＮＦＳのアクセス権限とＣＩＦＳのアクセス権限との両方を正確に制御することができるファイルサーバが切望されている。なお、本実施例では、ファイル作成要求としてディレクトリ作成要求を例にして説明するが、本発明はこれに限定されるものではなく、例えば、デバイスファイル、SOCKETファイルなどのファイル作成要求であっても本実施例を適用することができ、さらに、ファイル作成要求他に一般的なＵＮＩＸ（登録商標）のシステムコールにも適用することができる。

［ファイルサーバの概要および特徴］
次に、図１を用いて、実施例１に係るファイルサーバの概要および特徴を説明する。

このシステムは、上記したように、ユーザＩＤ「３３９４」が割り振られた利用者端末Ａと、ユーザＩＤ「２２００」が割り振られた利用者端末Ｂと、ファイルサーバとがネットワークで相互に通信可能に接続されている。また、利用者端末ＡとファイルサーバとはＣＩＦＳで接続されており、利用者端末ＢとファイルサーバとはＮＦＳで接続されている。

そして、ファイルサーバは、図２に示すように、アクセス要求先となるファイルシステムに対して、利用者端末が様々なアプリケーションから利用できるようにするＶＦＳ（Virtual File System）を起動しており、さらに、ＣＩＦＳを利用したアクセス要求を受け付けるためのプログラム（デーモン）としてＳａｍｂａのプログラムであるｓｍｂｄを起動しており、同様に、ＮＦＳを利用したアクセス要求を受け付けるためのｎｆｓｄを起動している。また、このファイルサーバは、ＵＮＩＸ（登録商標）系ＯＳ（Operating System）で使用されるアクセス制御情報を記憶している。なお、ここで示すアクセス制御とは、ＶＦＳ／ｅｘｔ３の間に割り込んでＮＴ−ＡＣＬ制御（アクセス制御）を実施するためのフックドライバである。

このような構成において、このファイルサーバは、上記したように、利用者端末とＣＩＦＳまたはＮＦＳで接続され、利用者端末からファイルシステムへのアクセス要求を受信して、当該アクセス要求を許可するか否かをファイルシステムの代わりに独自のアクセス制御で判定することを概要とするものであり、特に、正確なアクセス制御を備えたファイルサーバを、従来技術に比べ少ない工数で開発することが可能である点に主たる特徴がある。

この主たる特徴を具体的に説明すると、ファイルサーバは、ファイルシステムの各オブジェクトに対してアクセスを許可するか拒否するかを示すアクセス制御情報をアクセス制御情報ＤＢに記憶する。具体的に例を挙げれば、ファイルサーバは、「ALLOW FILE_WRITE_DATA 3394」、「DENY FILE_WRITE_EA 3394」や「ALLOW FILE_WRITE_EA 2211」などをアクセス制御情報としてアクセス制御情報ＤＢに記憶する。なお、ここで示した「ALLOW FILE_WRITE_DATA 3394」とは、ユーザＩＤ「3394」からのデータの書き込み「FILE_WRITE_DATA」を許可する（ALLOW）ことを示し、「DENY FILE_WRITE_EA 3394」とは、ユーザＩＤ「3394」からの拡張属性の書き込み「FILE_WRITE_EA」を拒否する（DENY）ことを示し、「ALLOW FILE_WRITE_EA 2211」とは、ユーザＩＤ「2211」からの拡張属性の書き込み「FILE_WRITE_EA」を許可する（ALLOW）ことを示している。

このような状態において、ファイルサーバは、ＣＩＦＳで接続される利用者端末からアクセス要求を受け付けた場合に、当該アクセス要求を、ＮＦＳで使用されるアクセス要求の基本権限である参照権、更新権、実行権のいずれかに対応付ける（図１の（１）と（２）参照）。上記した例で具体的に説明すると、ファイルサーバは、ＣＩＦＳで接続される利用者端末Ａからアクセス要求「SETPATHINFO」を受け付ける。すると、ファイルサーバは、当該アクセス要求に対応する権限である「FILE_WRITE_EA」が「拡張属性の書き込み」であることより、当該「FILE_WRITE_EA」をＮＦＳで使用されるアクセス要求の基本権限である参照権、更新権、実行権の「更新権（Write）」に対応付ける。

続いて、ファイルサーバは、アクセス制御情報ＤＢに記憶されるアクセス制御情報それぞれに対して基本権限の対応付けを行い、対応付けられた基本権限が、基本権限に対応付けたアクセス制御情報の一つ以上の構成要素に許可されていた場合に、当該基本権限を許可すると判定し、全ての構成要素に拒否されていた場合に、当該基本権限を拒否すると判定する（図１の（３）参照）。上記した例で具体的に説明すると、ファイルサーバは、アクセス要求「SETPATHINFO」の権限「FILE_WRITE_EA」が基本権限「Write」に対応付けられると、アクセス制御情報ＤＢに記憶されるアクセス制御情報それぞれに対して基本権限の対応付けを行う。例えば、ファイルサーバは、アクセス制御情報ＤＢに記憶される「ALLOW FILE_WRITE_DATA 3394」を「ALLOW Write」と対応付けたり、「DENY FILE_WRITE_EA 3394」を「DENY Write」と対応付けたりする。

そして、ファイルサーバは、対応付けられた基本権限「Write」が対応付けられたアクセス制御情報の一つ以上の構成要素に許可されているか、または、全ての構成要素に拒否されているかを判定する。ここでは、ファイルサーバは、アクセス制御情報を一番初めから参照していき、「ALLOW Write（ALLOW FILE_WRITE_DATA 3394）」が記憶されていることより、対応付けられた基本権限「Write」が許可されていると判定する。

そして、ファイルサーバは、許可された基本権限の元のアクセス要求に対して、アクセス制御情報ＤＢに記憶されるアクセス制御情報を参照し、当該アクセス要求を許可するか否かを判定する（図１の（４）参照）。上記した例で具体的に説明すると、ファイルサーバは、許可された基本権限「Write」の元のアクセス要求「SETPATHINFO」の権限である「FILE_WRITE_EA」に対して、アクセス制御情報ＤＢに記憶されるアクセス制御情報を参照していき、アクセス制御情報に「DENY FILE_WRITE_EA 3394」が含まれていることより、当該権限「FILE_WRITE_EA」を拒否する。そして、ファイルサーバは、当該アクセス要求を拒否したことを示す拒否応答を利用者端末Ａに送信する（図１の（５）参照）。

このように、実施例１に係るファイルサーバは、上記した主たる特徴のごとく、正確なアクセス制御を備えたファイルサーバを、従来技術に比べ少ない工数で開発することが可能である。

［ファイルサーバの構成］
次に、図３を用いて、図１に示したファイルサーバの構成を説明する。図３に示すように、このファイルサーバは、ｓｍｂｄ１１と、ｎｆｓｄ１２と、ＶＦＳ１３と、アクセス制御情報ＤＢ１４と第一アクセス制御部１５と第二アクセス制御部１６とから構成されるフックドライバと、ファイルシステム１７とから構成される。

ｓｍｂｄ１１は、ＣＩＦＳで接続される利用者端末からアクセス要求を受け付けた場合に、当該アクセス要求を、ＮＦＳで使用されるアクセス要求の基本権限である参照権、更新権、実行権のいずれかに対応付ける。上記した例で具体的に説明すると、ｓｍｂｄ１１は、ＣＩＦＳで接続される利用者端末Ａからアクセス要求「SETPATHINFO」を受け付ける。すると、ｓｍｂｄ１１は、当該アクセス要求を「拡張属性の書き込み」として解釈し、ＶＦＳ１３へ要求する。

ｎｆｓｄ１２は、ＮＦＳで接続される利用者端末からアクセス要求を受け付けた場合に、当該アクセス要求を、後述するＶＦＳ１３に出力する。具体的に例を挙げれば、ｎｆｓｄ１２は、ＮＦＳで接続される利用者端末からアクセス要求「ｍｋｄｉｒ」を受け付けた場合に、当該アクセス要求を後述するＶＦＳ１３に出力する。

ＶＦＳ１３は、ファイルシステム１７の上位に位置する抽象化層であり、利用者端末が様々なアプリケーションを用いてファイルシステムにアクセスできるようにする。上記した例で具体的に説明すると、ＶＦＳ１３は、ｓｍｂｄ11から受け付けた「拡張属性の書き込み」をＮＦＳで使用されるアクセス要求の基本権限である参照権、更新権、実行権の「更新権（Ｗｒｉｔｅ）」に対応付け、この基本権限「Write」のアクセス可否を判定するように後述する第一アクセス制御部１５に指示する。そして、ＶＦＳ１３は、後述する第二アクセス制御部１６によって実行された結果を受け付けて、当該結果を利用者端末に送信する。

例えば、第二アクセス制御部１６によって「mkdir」が実行されると、ＶＦＳ１３は、ファイルが作成されたことを利用者端末に送信し、また、利用者端末から受け付けられたアクセス要求が第二アクセス制御部１６によって「拒否」されると、ＶＦＳ１３は、その旨の応答を利用者端末に送信する。

アクセス制御情報ＤＢ１４は、ファイルシステム１７の各オブジェクトに対してアクセスを許可するか拒否するかを示すアクセス制御情報を記憶する。上記した例で具体的に説明すると、図４に示すように、アクセス制御情報ＤＢ１４は、「ALLOW FILE_LIST_DIRECTORY 3394」、「ALLOW FILE_READ_EA 3394」や「DENY WRITE_OWNER 3394」などを記憶する。なお、ここで示した「ALLOW FILE_LIST_DIRECTORY 3394」とは、ユーザＩＤ「3394」からのディレクトリにあるファイル一覧を参照することを「FILE_LIST_DIRECTORY」を許可する（ALLOW）ことを示し、「ALLOW FILE_READ_EA 3394」とは、ユーザＩＤ「3394」の拡張属性の読み出し「FILE_READ_EA」を許可する（ALLOW）ことを示し、「DENY WRITE_OWNER 3394」とは、ユーザＩＤ「3394」が現在操作しているファイルの所有者になることを「WRITE_OWNER」を拒否する（DENY）ことを示している。

また、ここで記憶されている「ALLOW FILE_READ_EA 3394」などの情報一つ一つをＡＣＥ（Access Control Entry）と呼ぶ。また、ここで示した各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。また、アクセス制御情報ＤＢ１４は、特許請求の範囲に記載の「アクセス制御情報記憶手段」に対応する。

第一アクセス制御部１５は、対応付けられた基本権限「Write」が対応付けられたアクセス制御情報の一つ以上の構成要素に許可されているか、または、全ての構成要素に拒否されているかを判定する。上記した例で具体的に説明すると、第一アクセス制御部１５は、ＶＦＳ１３から判定指示を受け付け、対応付けられた基本権限「Write」がアクセス制御情報ＤＢに記憶されるアクセス制御情報の一つ以上の構成要素に許可されているか、または、全ての構成要素に拒否されているかを判定し、その判定結果をＶＦＳ１３に出力する。ここでは、ファイルサーバは、アクセス制御情報を一番初めから参照していき、「ALLOW FILE_WRITE_DATA 3394」が記憶されていることより、対応付けられた基本権限「Write」が許可されていると判定する。なお、第一アクセス制御部１５は、特許請求の範囲に記載の「第一のアクセス制御手順」に対応する。

第二アクセス制御部１６は、許可された基本権限の元のアクセス要求に対して、アクセス制御情報ＤＢ１４に記憶されるアクセス制御情報を参照し、当該アクセス要求を許可するか否かを判定する。上記した例で具体的に説明すると、第二アクセス制御部１６は、ＶＦＳ１３から「FILE_WRITE_DATA」に対応する基本権限「Write」が許可されたことが通知されると、許可された基本権限「Write」の元のアクセス要求の権限「FILE_WRITE_DATA」に対して、アクセス制御情報ＤＢ１４に記憶されるアクセス制御情報を参照し、当該アクセス要求を許可するか否かを判定する。この場合、第二アクセス制御部１６は、アクセス制御情報ＤＢ１４にＡＣＥ「FILE_WRITE_DATA 3394」が記憶されていることより、当該アクセス要求を拒否し、拒否した旨をＶＦＳ１３に出力する。一方、当該アクセス要求を許可した場合、第二アクセス制御部１６は、ＶＦＳ１３を介してファイルシステム１７にディレクトリ作成の実行を指示する。なお、第二アクセス制御部１６は、特許請求の範囲に記載の「第二のアクセス制御手順」に対応する。

ファイルシステム１７は、ＯＳ（Operating System）が持つコンピュータの資源を操作するためのデータ、デバイス、プロセスやカーネルを備え、データの操作（アクセス、検索など）を実施するものであり、例を挙げると、ｅｘｔ２（second extended filesystem）やｅｘｔ３（third extended filesystem）などである。

［ファイルサーバによる処理］
次に、図５〜７を用いて、ファイルサーバによる処理を説明する。

（アクセス要求判定処理のフローチャート）
図５に示すように、ＣＩＦＳで接続される利用者端末からアクセス要求を受信すると（ステップＳ５０１肯定）、ファイルサーバのｓｍｂｄ１１は、当該アクセス要求に基づくＩ／Ｏ要求をＶＦＳ１３に発行する。ＶＦＳ１３は、当該Ｉ／Ｏ要求をＮＦＳで使用されるアクセス要求の基本権限である参照権、更新権、実行権のいずれかに対応付ける（ステップＳ５０２）。

そして、ＶＦＳ１３は、対応付けられた基本権限のアクセス可否を判定するように、第一アクセス制御部１５に指示する。第一アクセス制御部１５は、アクセス制御情報ＤＢ１４に記憶されるアクセス制御情報それぞれに対して基本権限の対応付けを行い、対応付けられた基本権限が、基本権限に対応付けたアクセス制御情報の一つ以上の構成要素に許可されていた場合に、当該基本権限を許可すると判定し、全ての構成要素に拒否されていた場合に、当該基本権限を拒否すると判定し、判定結果をＶＦＳ１３に応答する（ステップＳ５０３）。

そして、ＶＦＳ１３は、第一アクセス制御部１５からの応答がアクセス許可であった場合、（ステップＳ５０３肯定）、第二アクセス制御部に対して、許可された基本権限の元のアクセス要求の詳細なアクセス可否の判定を指示する。指示を受けた第二アクセス制御部１６は、アクセス制御情報ＤＢ１４に記憶されるアクセス制御情報を参照し、当該アクセス要求を許可するか否かを判定する（ステップＳ５０４）。

当該アクセス要求を許可すると判定すると（ステップＳ５０４肯定）、第二アクセス制御部１６は、Ｉ／Ｏ処理結果応答（アクセス許可応答）として、ＶＦＳ１３を介してファイルシステム１７に指示したディレクトリ作成処理の結果を、同じくＶＦＳ１３を介してｓｍｂｄ１１に通知する（ステップＳ５０５）。一方、当該アクセス要求を拒否すると判定すると（ステップＳ５０４否定）、第二アクセス制御部１６は、アクセス拒否応答として、ＶＦＳ１３を介して、当該アクセス要求が拒否されたことをｓｍｂｄ１１に通知する（ステップＳ５０６）。

また、ステップＳ５０３に戻り、基本権限が拒否されると判定すると（ステップＳ５０３否定）、ＶＦＳ１３は、当該アクセス要求に対してアクセス拒否応答を行う（ステップＳ５０６）。

（アクセス要求判定処理のシーケンス）
次に、図６を用いて、ＣＩＦＳでアクセス要求を受信した場合のファイルサーバ内での処理シーケンスについて説明する。また、ここでは、ファイルサーバが、利用者端末より「ディレクトリ作成」のアクセス要求を受信した場合について説明する。

図６に示すように、ＣＩＦＳでアクセス要求を受信したＳａｍｂａのプログラムであるｓｍｂｄ１１は、ＶＦＳ１３に対してシステムコール「sys_mkdir」を実行する（ステップＳ６０１）。すると、ＶＦＳ１３は、アクセス制御部（フックドライバ）に対してＦＳＩＦ（File System InterFace）を実行する（ステップＳ６０２）。また、ここで示すアクセス制御部（フックドライバ）とは、上記したアクセス制御情報ＤＢ１４、第一アクセス制御部１５、第二アクセス制御部１６とから構成されるものとする。

続いて、アクセス制御部は、ファイルシステム１７に対してのＦＳＩＦ「ext3_xattr_user_get」を実行して、拡張属性領域（ユーザ区分）を取得し、ＶＦＳ１３によってシステムコールが対応付けられた基本権限「Read、Write、Exec」を許可するか否かを判定し、その結果をＶＦＳ１３に通知する（ステップＳ６０３〜ステップＳ６０６）。ここでは、アクセス制御部により、基本権限が許可されたとする。

そして、基本権限が許可された旨を通知されたＶＦＳ１３は、アクセス制御部に対してＦＳＩＦ（mkdir）を実行する（ステップＳ６０７）。すると、アクセス制御部は、ファイルシステムに対してのＦＳＩＦ「ext3_xattr_user_get」を実行して、拡張属性領域（ユーザ区分）を取得するとともに、ＦＳＩＦ（mkdir）が許可されているか否かを判定する（ステップＳ６０８〜ステップＳ６１０）。

そして、ＦＳＩＦ（mkdir）が許可されていると判定すると、アクセス制御部は、ファイルシステムに「ディレクトリ作成」ＦＳＩＦである「ext3_mkdir」を実行し、その結果を取得してＶＦＳ１３に出力し、ＶＦＳ１３は、受け付けた結果をｓｍｂｄ１１を介して利用者端末に送信する（ステップＳ６１１〜ステップＳ６１４）。

（アクセスリストの評価ルール）
次に、受信したアクセス要求に対して許可するか拒否するかを判定する場合の処理は、一般的なアクセスリスト評価ルールに基本的に従って実施されるので、ここでは、図７を用いて、一般的なアクセス評価ルールの流れについて説明する。

図７に示すアクセス評価ルールでは、要求する全要求権限に対して、これを許可するＡＣＥが検出されるまで、または、要求する権限のうち、一つでも拒否するＡＣＥが検出されるまで、アクセス制御情報ＤＢ１４に記憶されるＡＣＥ配列を先頭から順に走査する。例えば、アクセス評価ルールでは、ＦＳＩＦ（mkdir）が要求する唯一の権限「FILE_ADD_SUBDIRECTORY」に対して、これを許可するＡＣＥ「ALLOW FILE_ADD_SUBDIRECTORY」が検出されるまで、またはこれを拒否するＡＣＥ「DENY FILE_ADD_SUBDIRECTORY」が検出されるまで、アクセス制御情報ＤＢ１４に記憶されるＡＣＥ配列を先頭から順に走査する。

図７に示すように、アクセス要求を受信したファイルサーバは、アクセス制御情報ＤＢ１４に当該アクセス要求の対象となるファイルに関する情報（ＡＣＬ）が記憶されているか否かを判定する（ステップＳ７０１）。

そして、記憶されていると判定すると（ステップＳ７０１肯定）、ファイルサーバは、アクセス制御情報ＤＢ１４に記憶されているＡＣＬで参照されていない未評価のＡＣＥが存在するか否かを判定する（ステップＳ７０２）。

未評価のＡＣＥが存在する場合（ステップＳ７０２肯定）、ファイルサーバは、当該ＡＣＥのＳＩＤが有効access-token（アクセス要求者の識別子ＳＩＤの集合）に含まれるか否かを判定する（ステップＳ７０３）。

続いて、当該ＡＣＥのＳＩＤが有効access-tokenに含まれる場合（ステップＳ７０３肯定）、ファイルサーバは、当該ＡＣＥ種別が「ＤＥＮＹ」か否かを判定する（ステップＳ７０４）。

その後、ファイルサーバは、当該ＡＣＥ種別が「ＤＥＮＹ」であり（ステップＳ７０４肯定）、かつ、当該ＡＣＥのＤＥＮＹ対象権限が要求権限に含まれる場合（ステップＳ７０５肯定）、当該アクセス要求を「拒否（ＤＥＮＹ）」と判定する（ステップＳ７０６）。

一方、ファイルサーバは、当該ＡＣＥ種別が「ＤＥＮＹ」でなく（ステップＳ７０４否定）、かつ、当該ＡＣＥのＡＬＬＯＷ対象権限が要求権限に含まれる場合（ステップＳ７０７肯定）、かつ、全要求権限のＡＣＥ照合が完了している場合（ステップＳ７０８肯定）、当該アクセス要求を「許可（ＡＬＬＯＷ）」と判定する（ステップＳ７０９）。

一方、ファイルサーバは、当該ＡＣＥのＳＩＤが有効access-tokenに含まれない場合（ステップＳ７０３否定）、当該ＡＣＥのＤＥＮＹ対象権限が要求権限に含まれない場合（ステップＳ７０５否定）、当該ＡＣＥのＡＬＬＯＷ対象権限が要求権限に含まれない場合（ステップＳ７０７否定）、全要求権限のＡＣＥ照合が完了していない場合（ステップＳ７０８否定）、ステップＳ７０２に戻り、以降の処理を実行する。

また、ファイルサーバは、アクセス要求を受け付けて、アクセス制御情報ＤＢ１４に当該アクセス要求の対象となるファイルに関する情報（ＡＣＬ）が記憶されていない場合（ステップＳ７０１否定）、当該アクセス要求を「許可（ＡＬＬＯＷ）」と判定し（ステップＳ７０９）、また、記憶されるアクセス制御情報のＡＣＬのうち、参照されていない未評価のＡＣＥが残っていない場合（ステップＳ７０２否定）、当該アクセス要求を「拒否（ＤＥＮＹ）」と判定する（ステップＳ７０６）。

［実施例１による効果］
このように、実施例１によれば、ファイルシステムの各オブジェクトに対してアクセス要求を許可するか拒否するかを示すアクセス制御情報を記憶し、ＮＦＳで使用されるアクセス要求の基本権限であって、ＣＩＦＳで接続される利用者端末から受け付けたアクセス要求に対して対応付けられた基本権限が許可されているか否かを、記憶されるアクセス制御情報それぞれに対して基本権限を対応付けたアクセス制御情報を参照して判定し、許可された基本権限の元のアクセス要求に対して、アクセス制御情報ＤＢ１４に記憶されるアクセス制御情報を参照し、当該アクセス要求を許可するか否かを判定するので、正確なアクセス制御を備えたファイルサーバを、従来技術に比べ少ない工数で開発することが可能である。

例えば、ＵＮＩＸ（登録商標）系システムの従来からの内部インターフェース仕様の都合で、アクセス要求を「参照権、更新権、実行権」の三種類でしかチェックすることができないが、Ｗｉｎｄｏｗｓ（登録商標）系のＣＩＦＳで接続される利用者端末から受信した、ＵＮＩＸ（登録商標）系のアクセス要求をさらに詳細に分類されたアクセス要求に対しても、一度、ＵＮＩＸ（登録商標）系のアクセス要求に変換し、その後、詳細なアクセス要求を判定することができる結果、ＵＮＩＸ（登録商標）系のアクセス要求に強引に対応付けたまま処理する必要がなく、詳細なアクセス要求のまま処理することができるので、正確なアクセス制御を実現することが可能である。

また、Ｗｉｎｄｏｗｓ（登録商標）やＵＮＩＸ（登録商標）に依存することのない独自のファイルサーバを開発する必要がなくＵＮＩＸ（登録商標）系のＯＳを利用してファイルサーバを開発して、両方の利用者端末からのアクセスを制御することができる結果、開発までに要する工数を短縮することが可能である。

また、実施例１によれば、ＣＩＦＳで接続される利用者端末から受け付けたアクセス要求に対して対応付けられた基本権限が、基本権限に対応付けたアクセス制御情報の一つ以上の構成要素に許可されていた場合に、当該基本権限を許可すると判定し、全ての構成要素に拒否されていた場合に、当該基本権限を拒否すると判定するので、はじめにアクセス要求を甘めに制御し、次に詳細にアクセス制御することができる結果、より正確なアクセス制御を実現することが可能である。

例えば、Ｗｉｎｄｏｗｓ（登録商標）系のアクセス要求である「FILE_WRITE_EA」を受信した場合、このアクセス要求は、ＵＮＩＸ（登録商標）系であると「Write」と変換される。そして、アクセス制御情報に「Write」に関する権限が一つでも許可されていれば、つまり、「FILE_WRITE_EA」に関係なく「FILE_WRITE_ATTRIBUTES」は「拒否」されているが「FILE_WRITE_DATA」が「許可」されていれば、受信したアクセス要求を「許可」とみなす。そして、次に実際の「FILE_WRITE_EA」が許可されているか否かを判定する。

一方、Ｗｉｎｄｏｗｓ（登録商標）系のアクセス要求である「FILE_WRITE_EA」を受信した場合、このアクセス要求は、ＵＮＩＸ（登録商標）系であると「Write」と変換される。そして、アクセス制御情報に「Write」に関する権限が全て拒否されていれば、つまり、「FILE_WRITE_EA」に関係なく「FILE_WRITE_ATTRIBUTES」も「拒否」、「FILE_WRITE_DATA」も「拒否」されていれば、受信したアクセス要求を「拒否」とみなして、当該「FILE_WRITE_EA」を拒否する。

このように、ＵＮＩＸ（登録商標）系システムの従来からの内部インターフェース仕様の都合で、アクセス要求を「参照権、更新権、実行権」の三種類でしかチェックすることができないため、Ｗｉｎｄｏｗｓ（登録商標）系のＣＩＦＳで接続される利用者端末から受信した詳細に分類されたアクセス要求をＵＮＩＸ（登録商標）系に置き換えて、第一のアクセス制御手順で厳しく、強引に判定すると、本当なら許可されるべきであった詳細なアクセス要求を拒否することになる恐れがある。そこで、はじめにアクセス要求を甘めに制御し、次に詳細にアクセス制御することで、このような誤判定を防止することができる結果、より正確なアクセス制御を実現することが可能である。

ところで、これまで実施例１についてアクセス制御情報、基本権限の対応付けには、様々な形態が考えられる。例えば、本発明に係るファイルサーバは、実施例１でアクセス制御情報ＤＢに記憶していたアクセス制御情報をファイルシステム上の各オブジェクトに関する情報を記憶する領域であるｉｎｏｄｅの拡張属性領域に記憶することもできる。例えば、図８に示すように、ファイルシステム（ext3）のｉｎｏｄｅ内の拡張属性領域（EA）に「user.nt_acl」を生成して、この領域にアクセス制御情報を記憶するようにしてもよい。

このようにすることで、アクセス制御情報や拡張メタデータを任意のフォーマットで生成することができる結果、ファイルシステムやＶＦＳの修正を最小限に留めることが可能である。例えば、拡張領域として、データフォーマットがあらかじめ定まっているＰＯＳＩＸ−ＡＣＬ／ＬＩＤＳ・ＳＥＬＩＮＵＸなどを使用せず、ＵＳＥＲ領域を使用することで、任意のデータフォーマットを使用することができるので、ファイルシステムやＶＦＳの修正を最小限に留めることが可能である。

また、実施例１で説明した受信したアクセス要求と基本権限の対応付けを、あらかじめ記憶しておいてもよい。例えば、図９に示すように、「FILE_READ_DATA（データの読み取り）」を「R（Read）」と対応付け、「WRITE_DAC（アクセス許可の変更）」を「Write」と対応付け、「FILE_TRAVERSE（エントリのLOOKUP）」を「X（実行）」などと対応付けた表を記憶しておき、この表を参照して、受信したアクセス要求を基本権限に変換するようにしてもよい。

ところで、本発明は、ファイルシステムにアクセス制御情報を格納する場合に、そのアトミック性を保証することもでき、さらに、実施例１とは異なり、ＣＩＦＳで接続される利用者端末から受信した要求に限り、２段階のアクセス制御の一段階目の処理を単にスキップすることも可能である。

そこで、実施例２では、アトミック性を保証したアクセス制御情報の格納と、１段階のアクセス制御で正確なアクセス制御を実施する場合について説明する。なお、実施例２で説明する各種関数については、説明上の例示であり、これに限定されるものではない。

（ファイルシステムの構成（実施例２））
まず、図１０を用いて、実施例２に係るファイルサーバの構成について説明する。図１０に示すように、このファイルサーバは、ｓｍｂｄ５１と、ＶＦＳ５２と、ｐｒｏｃｆｓ５３と、ｆｓｈｏｏｋ５４と、ｅｘｔ３／ｊｂｄ５９とから構成される。なお、ｓｍｂｄ５１とＶＦＳ５２とｅｘｔ３／ｊｂｄ５９とは、実施例１で説明したｓｍｂｄ１１とＶＦＳ１３とファイルシステム１７と同様の機能を有するので、その詳細な説明は省略し、ここでは、実施例１とは異なる機能を有するｐｒｏｃｆｓ５３と、ｆｓｈｏｏｋ５４とについて説明する。

ｐｒｏｃｆｓ５３は、ＶＦＳ５２とｆｓｈｏｏｋ５４との間に位置し、両者間のシステムコール以外の種別の通信を制御するインターフェースである。具体的に例をあげれば、ｐｒｏｃｆｓ５３は、ｓｍｂｄ５１から受け付けたアクセス要求やアクセス制御情報格納要求などをＶＦＳ５２を介して受け付け、当該受け付けた各種情報を後述するｆｓｈｏｏｋ５４のｐｒｏｃｆｓ制御部５６に通知する。

ｆｓｈｏｏｋ５４は、汎用ジャーナルデバイス機構（ｊｂｄ）を含むファイルシステムであるｅｘｔ３／ｊｂｄ５９への各種処理を制御するものであり、特に本発明に密接に関連するものとしては、ｓｂｌｏｃｋ／ｉｎｏｄｅ制御部５５と、ｐｒｏｃｆｓ制御部５６と、ｔａｓｋ制御部５７と、ｘａｔｔｒ制御部５８とを備える。

ｓｂｌｏｃｋ／ｉｎｏｄｅ制御部５５は、ファイルシステムであるｅｘｔ３／ｊｂｄ５９の各種制御をフックし、NT-ACL制御（アクセス制御）の機能を追加する。具体的に例をあげれば、ｓｂｌｏｃｋ／ｉｎｏｄｅ制御部５５は、fshookモジュールの初期化や終了を行う関数、FSIFのフック設定を行う関数、ext3への様々な処理（例えば、mount／unmount処理用、拡張属性設定処理用、属性／サイズ設定用など）を行うFSIFのフック関数などのNT-ACL制御（アクセス制御）の機能を追加する関数を備え、これらにより、ｅｘｔ３／ｊｂｄ５９の各種制御を過不足なくフックすることで、アクセス制御の機能を追加する。

ここで、本発明に特に関係のあるFSIFを含む三つの関数テーブル「file_system_type」、「super_operations」、「inode_operations」のフック方法（フック関数の設定方法）を説明する。まず、関数テーブル「file_system_type」は、FSボリュームのマウントを行うFSIF（get_sb）とアンマウントを行うFSIF（kill_sb）とを含むが、FSIF（get_sb）が関数テーブル「super_operations」の設定処理を行っており、FSIF（get_sb）をフックすれば関数テーブル「super_operations」のフックが可能になるため、関数テーブル「file_system_type」をフックする。例えば、ｆｓｆｏｏｋ５４をLKM（Loadable Kernel Module）として実装し、フック対象のFSボリュームのマウント前に強制的にロードし（例えば、rc.sysinitでルートパーティションのmount後にmodprobeでロードするなど）、そのロード時に呼ばれるmodule_init関数で、ｅｘｔ３／ｊｂｄ５９の関数テーブル「file_system_type」内のFSIF(get_sb)およびFSIF(kill_sb)を、ｆｓｆｏｏｋ５４を仲介するフック関数（fshook_get_sb）およびフック関数（fshook_kill_sb）に、それぞれ置き換える。

次に、関数テーブル「super_operations」は、superblock（FSボリューム）の操作を行うFSIF（alloc_inode）やFSIF（read_inode）などを含むが、FSIF(read_inode)が関数テーブル「inode_operations」の設定処理を行っており、FSIF(read_inode)をフックすれば関数テーブル「inode_operations」のフックが可能になるため、関数テーブル「super_operations」をフックする。例えば、前項のfile_system_typeのFSIF（get_sb）のフック関数（fshook_get_sb）において、ｅｘｔ３／ｊｂｄ５９のget_sb処理の終了後に、super_blockに設定されたｅｘｔ３／ｊｂｄ５９用suer_operationsを、ｆｓｈｏｏｋ５４を仲介するフック関数を含むように改ざんした複製に置き換える。

最後に、関数テーブル「inode_operations」は、inode（FSオブジェクト）を操作するFSIF(create)、FSIF(lookup)、FSIF(getattr)などを含むが、これらのFSIFに対してNT-ACL制御（アクセス制御）の機能拡張を施す必要があるため、関数テーブル「inode_operations」をフックする。例えば、ルートディレクトリの関数テーブル「inode_operations」に関しては、関数テーブル「super_operations」のフック関数設定と同タイミングで、super_blockに設定されたルートディレクトリのinodeを獲得し、そのinodeに設定されたｅｘｔ３／ｊｂｄ５９用の関数テーブル「inode_operations」を、ｆｓｈｏｏｋ５４を仲介するフック関数を含むように改ざんした複製に置き換える。また、例えば、ルートディレクトリ以外の既存ファイルの関数テーブル「inode_operations」に関しては、そのインコアinode初期化時のdisk-inodeイメージをロードするFSIF（read_inode）のフック関数（fshook_read_inode）において、ｅｘｔ３／ｊｂｄ５９における処理の終了後に、当該inodeに設定されたｅｘｔ３／ｊｂｄ５９用の関数テーブル「inode_operations」を、ｆｓｈｏｏｋ５４を仲介するフック関数を含むように改ざんした複製に置き換える。さらに、例えば、新規作成ファイルの関数テーブル「inode_operations」に関しては、その新規作成時の親ディレクトリの関数テーブル「inode_operations」の、FSIF(create)／FSIF(mkdir)／FSIF(symlink)において、ｅｘｔ３／ｊｂｄ５９における処理の終了後に、新規作成ファイルのinodeに設定されたｅｘｔ３／ｊｂｄ５９用の関数テーブル「inode_operation」を、ｆｓｈｏｏｋ５４を仲介するフック関数を含むように改ざんした複製に置き換える。

上記したフック関数の設定方法により、図１１に示すように、多種FS対応の目的で標準化／安定しているVFS／FS間インターフェース（FSIF）を選択的にフックし、当該FS（ext3）の処理を利用しつつ、必要に応じてNT-ACLに基づくアクセス制御を行うような機能拡張を施すことができるようになる。また、ファイルシステムのＦＳボリュームの原本を維持し、複製を改ざんすることで、superblock/inode単位に選択的にフックすることができる。例えば、「ext3_alloc_inode」のような機能追加が不要なＦＳＩＦについては、フックすることなく、ｅｘｔ３に処理を実行させ、「fshook_read_inode」、「fshoo_create」、「fshoo_get_sb」のような機能追加が必要なＦＳＩＦについては、ｆｓｈｏｏｋ５４にてフックする。

なお、ファイルシステムのボリュームのマウント要求に、当該ボリュームのＩ／Ｏのフックを指示するオプションを新規追加し、ＦＳＩＦ(get_sb)のフック関数fshook_get_sbで当該オプションを検出したときのみ、当該ボリュームの関数テーブル「super_operations」をフックすることも可能である。つまり、当該オプションにより、ボリューム毎の選択的なフックが可能である。

また、ファイルサーバは、上記した関数でフック中のボリューム数をフックドライバ内部でカウントし、このカウントが残るうちは、ドライバのアンロードを禁止するように制御することもできる。そうすることで、フックの中途離脱（FSインターフェースのリダイレクト先の消滅によるパニック停止）を防止することが可能である。

ｐｒｏｃｆｓ制御部５６は、ｐｒｏｃｆｓ５３を使用したｓｍｂｄ５１とのデータ受渡を制御する。具体的に例を挙げると、ｐｒｏｃｆｓ制御部５６は、ｆｓｈｏｏｋ５４のｐｒｏｃｆｓエントリの初期登録／終了処理を行う関数と、ｆｓｈｏｏｋ５４のモジュールリリース指示（unload条件の充足）に対して応答する関数、ｓｍｂｄ５１との通信セッション数を更新するための関数、sd（Security Descriptor）情報の設定および参照指示に対して応答する関数、ユーザメモリ空間またはカーネルメモリ空間上に各種データを取り込むための関数などを備え、こられによって、ｓｍｂｄ５１とのデータ受渡を制御する。

ｔａｓｋ制御部５７は、fshook連携smbdプロセスの生死確認およびtask単位のsyscall拡張データの受渡制御を行う。具体的に例を挙げれば、ｔａｓｋ制御部５７は、ｓｍｂｄ５１との連携セッションを管理するfshook_task構造体を新規に作成または破棄するための関数、連携セッションに対応するfshook_task構造体内に、ファイル又はディレクトリ作成時に使用するsd情報及びDOS attributeを設定するための関数と、ｓｍｂｄ５１との一つ一つの通信セッションに対応するfshook_task構造体内に設定されているsd情報及びDOS attribute情報のアドレスを算出またはクリアするための関数などを備え、これらによって、fshook連携smbdプロセスの生死確認およびtask単位のsyscall拡張データの受渡制御を行う。

また、ｔａｓｋ制御部５７は、カーネルtask構造体（task_struct）毎に、sambaからの通信状態制御と、sambaから提供されるシステムコール拡張用データ保存を司るfshook_task構造体（図１２参照）を管理する。図１２に示したfshook_task構造体は、procfsのcomファイルへのioctlで渡される要求データ（IOC_SD_PARAM）を渡されたままの状態でメンバft_dataにて内包し、FSIF(create)やFSIF(mkdir)等からの参照に備える。なお、本制御表は全てインコアであることからスピンロック（fshook_tlist_lock）で排他する。

ｘａｔｔｒ制御部５８は、ファイルシステム（ｅｘｔ３／ｊｂｄ５９）の拡張属性領域のNT-ACL対応用メタデータの制御（図８参照）を行う。具体的に例を挙げれば、ｘａｔｔｒ制御部５８は、NT-ACLに基づく処理権限チェックを行う関数、NT-ACLのデータまたはサイズの参照関数、NT-ACLの設定／更新／削除関数、DOS属性の設定／更新、DOS属性のデータまたはサイズの参照する関数、指定されたNT-ACL権限のうち許可されるものを列挙する関数と、prepareで設定済みのsd情報と親ディレクトリからの権限継承を考慮したNT-ACLを作成する関数などのアクセス制御に関する各種関数を備え、これらによって、ファイルシステムの拡張属性領域のNT-ACL対応用メタデータの制御を行う。

（処理の流れ（実施例２））
次に、図１３を用いて、実施例２に係る処理の流れを説明する。

なお、実施例２に係るファイルサーバにおいて、CIFSプロトコルによるファイル／ディレクトリ作成では、新規ファイル／ディレクトリに対するDOS属性やNT-ACLなどの付加的メタ情報の設定を指示できる。従来のLinuxシステムコールは、これらの付加的メタ情報を伝達できないため、システムコール発行前に別IOCTLで付加情報を提供する。

図１３に示すように、ｓｍｂｄ５１は、利用者端末からＣＩＦＳプロトコルによるディレクトリ作成要求を受け付けた後、ディレクトリ作成を行うシステムコール「sys_mkdir」をＶＦＳ５２に発行する前に、当該システムコールとは異なるＩＯコントロール（ioctl（PREPARE））を介して、作成されるディレクトリ用のアクセス制御情報をＶＦＳ５２に送信し（ステップＳ１３０１）、ＶＦＳ５２は、当該アクセス制御情報が付加されたＩＯコントロールを「com_ioctl」としてｆｓｈｏｏｋ５４に出力する（ステップＳ１３０２）。

次に、ｆｓｈｏｏｋ５４は、ＶＦＳ５２から受け付けたアクセス制御情報である「DOS属性」と「初期ACL」とコンテキストとを所定の記憶領域（例えば、一時領域など）に蓄積し（ステップＳ１３０３）、その応答をＶＦＳ５２を介してｓｍｂｄ５１に通知する（ステップＳ１３０４とステップＳ１３０５）。

その後、ｓｍｂｄ５１から「sys_mkdir」を受け付けたＶＦＳ５２は、このコールを予め設定されていたフック関数fshook_mkdirを通して、ｆｓｈｏｏｋ５４に通知する（ステップＳ１３０６とステップＳ１３０７）。

次に、ｆｓｈｏｏｋ５４は、ファイルシステム（ｊｂｄ）に対してＦＳＩＦ「ext3_xattr_user_get」を実行して、拡張属性領域（ユーザ区分）を取得する（ステップＳ１３０８とステップＳ１３０９）。

そして、拡張属性領域（ユーザ区分）を取得したｆｓｈｏｏｋ５４は、ファイルシステム（ｊｂｄ）に対して、アクセス制御情報を格納するジャーナルを開始するＦＳＩＦ「journal_start」をファイルシステム（ｊｂｄ）に対して発行し（ステップＳ１３１０とステップＳ１３１１）、これ以降の処理について、ファイルシステムで実施される各メタデータ更新処理のための各ジャーナルと同一ジャーナルセッションで括って格納処理を実行することで、システムコール「sys_mkdir」としての全メタデータ更新のアトミック性を保証する（ステップＳ１３１２）。

続いて、ｆｓｈｏｏｋ５４は、ファイルシステム（ext3）にＦＳＩＦ「ディレクトリ作成」の「ext3_mkdir」を実行して「ディレクトリ作成＝ＭＫＤＩＲ」を実行するとともに（ステップＳ１３１３とステップＳ１３１４）、「ディレクトリ作成」のジャーナルを開始するＦＳＩＦ「journal_start」をｊｂｄに発行する（ステップＳ１３１５とステップＳ１３１６）。

そして、「ディレクトリ作成」が終了したｅｘｔ３は、「ディレクトリ作成」のジャーナルを終了するＦＳＩＦ「journal_stop」をｊｂｄに発行する（ステップＳ１３１７）。

その後、「ディレクトリ作成」のジャーナルを終了したことをｊｄｂおよびｅｘｔ３を介して受け取ったｆｓｈｏｏｋ５４は、所定の記憶領域に蓄積されているコンテキストの照合を行い、格納しようとするアクセス制御情報がステップＳ１３０３で格納したアクセス制御情報と一致するかの判定を行う（ステップＳ１３１８〜ステップＳ１３２０）。

所定の記憶領域に蓄積されているコンテキストが一致することで、アクセス制御情報がステップＳ１３０３で格納したアクセス制御情報であると判定されると、ｆｓｈｏｏｋ５４は、ファイルシステム（ext3）に対してＦＳＩＦ「ext3_xattr_user_set」を発行する（ステップＳ１３２１）。

このＦＳＩＦを受け取ったｅｘｔ３は、「アクセス制御情報格納処理」のジャーナルを開始するＦＳＩＦ「journal_start」をｊｂｄに発行してから（ステップＳ１３２３とステップＳ１３３４）、所定の記憶領域に蓄積されているアクセス制御情報を取得して拡張領域（inode）に格納する「アクセス制御情報格納処理（DOS属性および初期ACLの反映処理）」を実行する（ステップＳ１３２２）。

そして、「アクセス制御情報格納処理」が終了したｅｘｔ３は、「アクセス制御情報格納処理」のジャーナルを終了するＦＳＩＦ「journal_stop」をｊｂｄに発行する（ステップＳ１３２５）。

その後、「アクセス制御情報格納処理」のジャーナルを終了したことをｊｂｄおよびｅｘｔ３を介して受け取ったｆｓｈｏｏｋ５４は（ステップＳ１３２６とステップＳ１３２７）、アクセス制御情報を格納するジャーナルを終了するＦＳＩＦ「journal_stop」をｊｂｄに対して発行し（ステップＳ１３２８）、その結果をｊｂｄから受け取って、ｓｍｂｄ５１を介して利用者端末に通知する（ステップＳ１３２９）。

（ＡＣＬ継承処理の流れ（実施例２））
そして、図１３で説明したディレクトリ新規作成処理ではＡＣＬ初期設定が明示的に指示されていたが、ＡＣＬ初期設定が明示的に指示されていないような場合は、代わりに親ディレクトリのＡＣＬを継承する。正規のルールに則り、継承先ファイルがＡＣＬ継承を禁止しない場合に限り、親ディレクトリのＡＣＬを走査しＡＣＥを選択的に継承する。

そこで、ここでは、図１４を用いて、実施例２に係るＡＣＬ継承処理の流れを説明する。

図１４に示すように、継承先のファイルが継承を拒否することなく継承処理が開始されと（ステップＳ１４０１否定）、ファイルサーバは、現在参照している継承元ファイルのＡＣＬのチェック中ＡＣＥのファイルタイプ属性データが、継承先ファイルタイプと合致するかの照合を行う（Ｓ１４０２）。これが合致する場合（ステップＳ１４０２肯定）、当該ＡＣＥのＳＩＤがＣＲＥＡＴＥ＿ＯＷＮＥＲであるか否かを判定する（ステップＳ１４０３）。

そして、当該ＡＣＥのＳＩＤがＣＲＥＡＴＥ＿ＯＷＮＥＲでない場合（ステップＳ１４０３否定）、ファイルサーバは、当該ＡＣＥのＳＩＤがＣＲＥＡＴＥ＿ＧＲＯＵＰであるか否かを判定する（ステップＳ１４０４）。

その後、当該ＡＣＥのＳＩＤがＣＲＥＡＴＥ＿ＧＲＯＵＰでない場合（ステップＳ１４０４否定）、ファイルサーバは、当該ＡＣＥが継承伝播禁止のＡＣＥであるか否かを判定する（ステップＳ１４０５）。

続いて、当該ＡＣＥが継承伝播禁止のＡＣＥでない場合（ステップＳ１４０５否定）、ファイルサーバは、継承用ＡＣＥを継承先ファイルのＡＣＬ末端に追加し（ステップＳ１４０６）、当該ＡＣＥが継承元ＡＣＬの末端であるか否かを判定する（ステップＳ１４０７）。

そして、ファイルサーバは、当該ＡＣＥが継承元ＡＣＬの末端である場合に（ステップＳ１４０７肯定）、処理を終了し、当該ＡＣＥが継承元ＡＣＬの末端でない場合に（ステップＳ１４０７否定）、ステップＳ１４０２以降の処理を繰り返す。

一方、ステップＳ１４０３に戻り、ファイルサーバは、当該ＡＣＥのＳＩＤがＣＲＥＡＴＥ＿ＯＷＮＥＲである場合（ステップＳ１４０３肯定）、当該ＡＣＥのＳＩＤを継承先ファイル作成者に修正した継承用ＡＣＥを作成（複製）してステップＳ１４０５の処理を行って（ステップＳ１４０８）、ステップＳ１４０５以降の処理を実行する。

また、当該ＡＣＥのＳＩＤがＣＲＥＡＴＥ＿ＧＲＯＵＰである場合（ステップＳ１４０４肯定）、当該ＡＣＥのＳＩＤを継承先ファイル作成グループに修正した継承用ＡＣＥを作成（複製）して（ステップＳ１４０９）、ステップＳ１４０５以降の処理を実行する。

また、当該ＡＣＥが継承伝播禁止のＡＣＥである場合（ステップＳ１４０５肯定）、ファイルサーバは、継承先ファイル種別情報をクリアすることで、子ディレクトリへ継承された後のＡＣＥがさらに孫ディレクトリ作成時に孫ディレクトリへ継承されることを防ぎ（ステップＳ１４１０）、ステップＳ１４０６以降の処理を実行する。

（ＮＴ−ＡＣＬ評価処理の流れ（実施例２））
次に、図１５を用いて、図１３と図１４とに示した処理シーケンスにより格納されたアクセス制御情報を用いてアクセス制御（ＮＴ−ＡＣＬ評価処理）を行う処理の流れについて説明する。

図１５に示すように、アクセス要求を受け付けて、当該アクセス要求に対応するＡＣＬがｉｎｏｄｅに記憶されている場合（ステップＳ１５０１肯定）、ファイルサーバは、記憶されるアクセス制御情報のＡＣＬうち、参照されていない未評価のＡＣＥが残っているか否かを判定する（ステップＳ１５０２）。

未評価のＡＣＥが存在する場合（ステップＳ１５０２肯定）、ファイルサーバは、当該ＡＣＥのＳＩＤが有効access-token（アクセス要求者の識別子ＳＩＤの集合）に含まれるか否かを判定する（ステップＳ１５０３）。

続いて、当該ＡＣＥのＳＩＤが有効access-tokenに含まれる場合（ステップＳ１５０３肯定）、ファイルサーバは、当該ＡＣＥ種別が「ＤＥＮＹ」か否かを判定する（ステップＳ１５０４）。

その後、ファイルサーバは、当該ＡＣＥ種別が「ＤＥＮＹ」であり（ステップＳ１５０４肯定）、かつ、当該ＡＣＥのＤＥＮＹ対象権限が要求権限に含まれる場合（ステップＳ１５０５肯定）、当該アクセス要求を「拒否（ＤＥＮＹ）」と判定する（ステップＳ１５０６）。

一方、ファイルサーバは、当該ＡＣＥ種別が「ＤＥＮＹ」でなく（ステップＳ１５０４否定）、かつ、当該ＡＣＥのＡＬＬＯＷ対象権限が要求権限に含まれる場合（ステップＳ１５０７肯定）、かつ、全要求権限のＡＣＥ照合が完了している場合（ステップＳ１５０８肯定）、当該アクセス要求を「許可（ＡＬＬＯＷ）」と判定する（ステップＳ１５０９）。

一方、ファイルサーバは、当該ＡＣＥのＳＩＤが有効access-tokenに含まれない場合（ステップＳ１５０３否定）、当該ＡＣＥのＤＥＮＹ対象権限が要求権限に含まれない場合（ステップＳ１５０５否定）、当該ＡＣＥのＡＬＬＯＷ対象権限が要求権限に含まれない場合（ステップＳ１５０７否定）、全要求権限のＡＣＥ照合が完了していない場合（ステップＳ１５０８否定）、ステップＳ１５０２に戻り、以降の処理を実行する。

また、ファイルサーバは、アクセス要求を受け付けて、当該アクセス要求の対象ファイルのｉｎｏｄｅにＮＴ−ＡＣＬ情報が記憶されていない場合（ステップＳ１５０１否定）、当該アクセス要求を「許可（ＡＬＬＯＷ）」と判定し（ステップＳ１５０９）、また、記憶されるアクセス制御情報のＡＣＬのうち、参照されていない未評価のＡＣＥが残っていない場合（ステップＳ１５０２否定）、当該アクセス要求を「拒否（ＤＥＮＹ）」と判定する（ステップＳ１５０６）。

（実施例２よる効果）
このように、実施例２によれば、ＣＩＦＳで接続される利用者端末からディレクトリ作成要求を受け付けた場合に、当該ディレクトリ作成要求に応答してディレクトリ作成を行うシステムコールを発行する前に、前記ファイルシステムの各オブジェクトに対してアクセス要求を許可するか拒否するかを示す当該ディレクトリ用のアクセス制御情報を、当該システムコールとは異なるＩＯコントロールを介して発行し、ＩＯコントロールを介して発行されたアクセス制御情報を、ファイルシステム上のｉｎｏｄｅの拡張属性領域に格納する格納処理を実行するのに際して、ファイルシステムで実施される各メタデータ更新処理のための各ジャーナルと同一ジャーナルセッションで括って、格納処理を実行し、ＣＩＦＳで接続される利用者端末からアクセス要求を受け付けた場合に、ファイルシステムに格納されたアクセス制御情報に基づいて、当該アクセス要求を許可するか否かを判定するので、アトミック性が保証されたアクセス制御情報を用いてアクセス制御を実施することができる結果、ＵＮＩＸ（登録商標）系のアクセス要求に強引に対応付けたまま処理する必要がなく、詳細なアクセス要求のまま処理することができるので、より正確なアクセス制御を実現することが可能である。

また、実施例２によれば、ＣＩＦＳで接続される利用者端末からアクセスされるファイルシステムのボリュームに関してファイルシステムのルートディレクトリおよびメタデータに関するインターフェースをフックし、当該マウント先のディレクトリに関するインターフェースをフックするのに際して、当該ディレクトリ直下のファイルに関するインターフェースをフックすることで、前記マウントされたボリュームに関するファイルシステムインターフェースを過不足なくフックするので、インターフェース関数ベクターを改ざんするのではなく、そのポインタ元（例えば、スーパーブロックやinodeなど）のポインタを改ざん版インターフェース関数ベクターへリダイレクトすることができる結果、ボリューム限定のフック設定を実現すると共に、フック対象外ボリュームとのフック設定処理に関する排他制御を不要化することが可能である。

また、実施例２によれば、ＣＩＦＳで接続される利用者端末からアクセスされるファイルシステムのボリュームに関して当該ボリュームをマウントするマウント要求に含まれるマウントオプションにフック対象であることを示す識別子が付加されている場合にのみ、当該ボリュームがフック対象であると判定するので、無関係なボリュームに関するフックの設定を回避することが可能である。

また、実施例２によれば、フック中のボリューム数をフックドライバ内部でカウントし、このカウントが残るうちは、ドライバのアンロードを禁止するので、フックの中途離脱（FSインターフェースのリダイレクト先の消滅によるパニック停止）を防止することが可能である。

また、実施例２によれば、アクセス制御情報をファイルシステム上のｉｎｏｄｅの拡張属性領域に格納する場合に、ＩＯコントロールにおいて、当該アクセス制御情報と共にコンテキストをカーネル内フックドライバに一時的に格納し、システムコールにおいて、当該コンテキストが一致しているかを判定し、当該アクセス制御情報が受け付けられた正当なアクセス制御情報であることを条件として、拡張属性領域に格納するので、ＩＯコントロールとシステムコールの関連を適切に判断することが可能である。

さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下に示すように、（１）ＳａｍｂａによるＣＩＦＳ接続、（２）システム構成等、（３）プログラム、にそれぞれ区分けして異なる実施例を説明する。

（１）ＳａｍｂａによるＣＩＦＳ接続
実施例１では、Ｓａｍｂａのプログラム（smbdデーモン）を実行して、ＣＩＦＳ接続される利用者端末からのアクセス要求を受信する場合について説明したが、本発明はこれに限定されるものではなく、例えば、独自のプログラムやＣＩＦＳ接続を可能とする公知の技術、プログラムなどを利用することもできる。

（２）システム構成等
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合（例えば、第一アクセス制御部と第二アクセス制御部とを統合するなど）して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理（例えば、受信したアクセス要求をＣＩＦＳかＮＦＳか判定する処理など）の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理（例えば、アクセス制御情報の作成処理など）の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報（例えば、図４、図８、図９など）については、特記する場合を除いて任意に変更することができる。

（３）プログラム
ところで、上記の実施例で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータシステムで実行することによって実現することができる。そこで、以下では、上記の実施例と同様の機能を有するプログラムを実行するコンピュータシステムを他の実施例として説明する。

図１６に示すように、コンピュータシステム１００は、ＲＡＭ１０１と、ＨＤＤ１０２と、ＲＯＭ１０３と、ＣＰＵ１０４とから構成される。ここで、ＲＯＭ１０３には、上記の実施例と同様の機能を発揮するプログラム、つまり、図１６に示すように、アクセス対応プログラム１０３ａと、第一アクセス制御プログラム１０３ｂと、第二アクセス制御プログラム１０３ｃとがあらかじめ記憶されている。

そして、ＣＰＵ１０４には、これらのプログラム１０３ａ〜１０３ｃを読み出して実行することで、図１６に示すように、アクセス対応プロセス１０４ａと、第一アクセス制御プロセス１０４ｂと、第二アクセス制御プロセス１０４ｃとなる。なお、アクセス対応プロセス１０４ａは、図３に示した、ｓｍｂｄ１１に対応し、同様に、第一アクセス制御プロセス１０４ｂは、第一アクセス制御部１５に対応し、第二アクセス制御プロセス１０４ｃは、第二アクセス制御部１６に対応する。

また、ＨＤＤ１０２には、ファイルシステムの各オブジェクトに対してアクセスを許可するか拒否するかを示すアクセス制御情報を記憶するアクセス制御情報テーブル１０２ａが設けられる。なお、アクセス制御情報テーブル１０２ａは、図３に示した、アクセス制御情報ＤＢ１４に対応する。

ところで、上記したプログラム１０３ａ〜１０３ｃは、必ずしもＲＯＭ１０３に記憶させておく必要はなく、例えば、コンピュータシステム１００に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯディスク、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」の他に、コンピュータシステム１００の内外に備えられるハードディスクドライブ（ＨＤＤ）などの「固定用の物理媒体」、さらに、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータシステム１００に接続される「他のコンピュータシステム」に記憶させておき、コンピュータシステム１００がこれらからプログラムを読み出して実行するようにしてもよい。

（付記１）利用者端末とＣＩＦＳまたはＮＦＳで接続され、前記利用者端末からファイルシステムへのアクセス要求を受信して、当該アクセス要求を許可するか否かを判定することをコンピュータに実行させるアクセス制御プログラムであって、
前記ファイルシステムの各オブジェクトに対してアクセス要求を許可するか拒否するかを示すアクセス制御情報を記憶するアクセス制御情報記憶手段と、
前記ＮＦＳで使用されるアクセス要求の基本権限であって、前記ＣＩＦＳで接続される利用者端末から受け付けたアクセス要求に対して対応付けられた前記基本権限が許可されているか否かを、前記アクセス制御情報記憶手段に記憶されるアクセス制御情報それぞれに対して前記基本権限を対応付けたアクセス制御情報を参照して判定する第一のアクセス制御手順と、
前記第一のアクセス制御手順により許可された基本権限の元のアクセス要求に対して、前記アクセス制御情報記憶手段に記憶されるアクセス制御情報を参照し、当該アクセス要求を許可するか否かを判定する第二のアクセス制御手順と、
をコンピュータに実行させることを特徴とするアクセス制御プログラム。

（付記２）前記第一のアクセス制御手順は、前記ＣＩＦＳで接続される利用者端末から受け付けたアクセス要求に対して対応付けられた基本権限が、前記基本権限に対応付けたアクセス制御情報の一つ以上の構成要素に許可されていた場合に、当該基本権限を許可すると判定し、全ての構成要素に拒否されていた場合に、当該基本権限を拒否すると判定することを特徴とする付記１に記載のアクセス制御プログラム。

（付記３）前記アクセス制御情報記憶手段は、前記ファイルシステム上の各オブジェクトに関する情報を記憶するｉｎｏｄｅの拡張属性領域に、前記アクセス制御情報を記憶することを特徴とする付記１または２に記載のアクセス制御プログラム。

（付記４）利用者端末とＣＩＦＳまたはＮＦＳで接続され、前記利用者端末からファイルシステムへのアクセス要求を受信して、当該アクセス要求を許可するか否かを判定するアクセス制御装置であって、
前記ファイルシステムの各オブジェクトに対してアクセス要求を許可するか拒否するかを示すアクセス制御情報を記憶するアクセス制御情報記憶手段と、
前記ＮＦＳで使用されるアクセス要求の基本権限であって、前記ＣＩＦＳで接続される利用者端末から受け付けたアクセス要求に対して対応付けられた前記基本権限が許可されているか否かを、前記アクセス制御情報記憶手段に記憶されるアクセス制御情報それぞれに対して前記基本権限を対応付けたアクセス制御情報を参照して判定する第一のアクセス制御手段と、
前記第一のアクセス制御手段により許可された基本権限の元のアクセス要求に対して、前記アクセス制御情報記憶手段に記憶されるアクセス制御情報を参照し、当該アクセス要求を許可するか否かを判定する第二のアクセス制御手段と、
を備えたことを特徴とするアクセス制御装置。

（付記５）前記第一のアクセス制御手段は、前記ＣＩＦＳで接続される利用者端末から受け付けたアクセス要求に対して対応付けられた基本権限が、前記基本権限に対応付けたアクセス制御情報の一つ以上の構成要素に許可されていた場合に、当該基本権限を許可すると判定し、全ての構成要素に拒否されていた場合に、当該基本権限を拒否すると判定することを特徴とする付記４に記載のアクセス制御装置。

（付記６）前記アクセス制御情報記憶手段は、前記ファイルシステム上の各オブジェクトに関する情報を記憶するｉｎｏｄｅの拡張属性領域に、前記アクセス制御情報を記憶することを特徴とする付記４または５に記載のアクセス制御装置。

（付記７）利用者端末とＣＩＦＳまたはＮＦＳで接続され、前記利用者端末からファイルシステムへのアクセス要求を受信して、当該アクセス要求を許可するか否かを判定することに適したアクセス制御方法であって、
前記ファイルシステムの各オブジェクトに対してアクセス要求を許可するか拒否するかを示すアクセス制御情報を記憶するアクセス制御情報記憶手段と、
前記ＮＦＳで使用されるアクセス要求の基本権限であって、前記ＣＩＦＳで接続される利用者端末から受け付けたアクセス要求に対して対応付けられた前記基本権限が許可されているか否かを、前記アクセス制御情報記憶手段に記憶されるアクセス制御情報それぞれに対して前記基本権限を対応付けたアクセス制御情報を参照して判定する第一のアクセス制御工程と、
前記第一のアクセス制御工程により許可された基本権限の元のアクセス要求に対して、前記アクセス制御情報記憶手段に記憶されるアクセス制御情報を参照し、当該アクセス要求を許可するか否かを判定する第二のアクセス制御工程と、
を含んだことを特徴とするアクセス制御方法。

（付記８）前記第一のアクセス制御工程は、前記ＣＩＦＳで接続される利用者端末から受け付けたアクセス要求に対して対応付けられた基本権限が、前記基本権限に対応付けたアクセス制御情報の一つ以上の構成要素に許可されていた場合に、当該基本権限を許可すると判定し、全ての構成要素に拒否されていた場合に、当該基本権限を拒否すると判定することを特徴とする付記７に記載のアクセス制御方法。

（付記９）前記アクセス制御情報記憶手段は、前記ファイルシステム上の各オブジェクトに関する情報を記憶するｉｎｏｄｅの拡張属性領域に、前記アクセス制御情報を記憶することを特徴とする付記７または８に記載のアクセス制御方法。

（付記１０）利用者端末とＣＩＦＳまたはＮＦＳで接続され、前記利用者端末からファイルシステムへのアクセス要求を受信して、当該アクセス要求を許可するか否かを判定することをコンピュータに実行させるアクセス制御プログラムであって、
前記ＣＩＦＳで接続される利用者端末からファイル作成要求を受け付けた場合に、当該ファイル作成要求に応答してファイル作成を行うシステムコールを発行する前に、前記ファイルシステムの各オブジェクトに対してアクセス要求を許可するか拒否するかを示す当該ファイル用のアクセス制御情報を、当該システムコールとは異なるＩＯコントロールを介して発行するアクセス制御情報発行手順と、
前記アクセス制御情報発行手順によりＩＯコントロールを介して発行されたアクセス制御情報を、前記ファイルシステム上のｉｎｏｄｅの拡張属性領域に格納する格納処理を実行するのに際して、前記ファイルシステムで実施される各メタデータ更新処理のための各ジャーナルと同一ジャーナルセッションで括って、前記格納処理を実行する格納処理手順と、
前記ＣＩＦＳで接続される利用者端末からアクセス要求を受け付けた場合に、前記格納処理手順によってファイルシステムに格納されたアクセス制御情報に基づいて、当該アクセス要求を許可するか否かを判定するアクセス制御手順と、
をコンピュータに実行させることを特徴とするアクセス制御プログラム。

（付記１１）前記ＣＩＦＳで接続される利用者端末からアクセスされるファイルシステムのボリュームに関して、前記ファイルシステムのルートディレクトリおよびメタデータに関するインターフェースをフックし、当該マウント先のディレクトリに関するインターフェースをフックするのに際して、当該ディレクトリ直下のファイルに関するインターフェースをフックすることで、前記マウントされたボリュームに関するファイルシステムインターフェースを過不足なくフックするフック制御手順をさらにコンピュータに実行させることを特徴とする付記１０に記載のアクセス制御プログラム。

（付記１２）前記フック制御手順は、前記ＣＩＦＳで接続される利用者端末からアクセスされるファイルシステムのボリュームに関して、当該ボリュームをマウントするマウント要求に含まれるマウントオプションにフック対象であることを示す識別子が付加されている場合にのみ、当該ボリュームがフック対象であると判定することを特徴とする付記１１に記載のアクセス制御プログラム。

（付記１３）前記フック制御手順は、フック中のボリューム数をフックドライバ内部でカウントし、このカウントが残るうちは、ドライバのアンロードを禁止することを特徴とする付記１１または１２に記載のアクセス制御プログラム。

（付記１４）前記格納処理手順は、前記アクセス制御情報をファイルシステム上のｉｎｏｄｅの拡張属性領域に格納する場合に、前記ＩＯコントロールにおいて、当該アクセス制御情報と共にコンテキストをカーネル内フックドライバに一時的に格納し、前記システムコールにおいて、当該コンテキストが一致しているかを判定し、当該アクセス制御情報が前記アクセス制御情報受付手順により受け付けられた正当なアクセス制御情報であることを条件として、前記拡張属性領域に格納することを特徴とする付記１０〜１３のいずれか一つに記載のアクセス制御プログラム。

（付記１５）利用者端末とＣＩＦＳまたはＮＦＳで接続され、前記利用者端末からファイルシステムへのアクセス要求を受信して、当該アクセス要求を許可するか否かを判定するアクセス制御装置であって、
前記ＣＩＦＳで接続される利用者端末からファイル作成要求を受け付けた場合に、当該ファイル作成要求に応答してファイル作成を行うシステムコールを発行する前に、前記ファイルシステムの各オブジェクトに対してアクセス要求を許可するか拒否するかを示す当該ファイル用のアクセス制御情報を、当該システムコールとは異なるＩＯコントロールを介して発行するアクセス制御情報発行手段と、
前記アクセス制御情報発行手段によりＩＯコントロールを介して発行されたアクセス制御情報を、前記ファイルシステム上のｉｎｏｄｅの拡張属性領域に格納する格納処理を実行するのに際して、前記ファイルシステムで実施される各メタデータ更新処理のための各ジャーナルと同一ジャーナルセッションで括って、前記格納処理を実行する格納処理手段と、
前記ＣＩＦＳで接続される利用者端末からアクセス要求を受け付けた場合に、前記格納処理手段によってファイルシステムに格納されたアクセス制御情報に基づいて、当該アクセス要求を許可するか否かを判定するアクセス制御手順と、
を備えたことを特徴とするアクセス制御装置。

（付記１６）利用者端末とＣＩＦＳまたはＮＦＳで接続され、前記利用者端末からファイルシステムへのアクセス要求を受信して、当該アクセス要求を許可するか否かを判定することに適したアクセス制御方法であって、
前記ＣＩＦＳで接続される利用者端末からファイル作成要求を受け付けた場合に、当該ファイル作成要求に応答してファイル作成を行うシステムコールを発行する前に、前記ファイルシステムの各オブジェクトに対してアクセス要求を許可するか拒否するかを示す当該ファイル用のアクセス制御情報を、当該システムコールとは異なるＩＯコントロールを介して発行するアクセス制御情報発行工程と、
前記アクセス制御情報発行工程によりＩＯコントロールを介して発行されたアクセス制御情報を、前記ファイルシステム上のｉｎｏｄｅの拡張属性領域に格納する格納処理を実行するのに際して、前記ファイルシステムで実施される各メタデータ更新処理のための各ジャーナルと同一ジャーナルセッションで括って、前記格納処理を実行する格納処理工程と、
前記ＣＩＦＳで接続される利用者端末からアクセス要求を受け付けた場合に、前記格納処理手順によってファイルシステムに格納されたアクセス制御情報に基づいて、当該アクセス要求を許可するか否かを判定するアクセス制御工程と、
を含んだことを特徴とするアクセス制御方法。

以上のように、本発明に係るアクセス制御プログラムは、利用者端末とＣＩＦＳまたはＮＦＳで接続され、利用者端末からファイルシステムへのアクセス要求を受信して、当該アクセス要求を許可するか否かを判定することに有用であり、特に、ファイルサーバを開発する工数を短縮することが可能であり、正確なアクセス制御を実現することに適する。

実施例１に係るファイルサーバを含むシステムの全体構成を示すシステム構成図である。 実施例１に係るファイルサーバを説明するための図である。 実施例１に係るファイルサーバの構成を示すブロック図である。 アクセス制御情報ＤＢに記憶される情報の例である。 実施例１に係るファイルサーバにおけるアクセス要求判定処理の流れを示すフローチャートである。 実施例１に係るファイルサーバにおけるアクセス要求判定処理の流れを示すシーケンス図である。 アクセス評価ルールの流れを示すフローチャートである。 拡張属性領域を使用してアクセス制御情報を記憶する場合の例を示す図である。 アクセス要求と基本権限とを対応付けた表の例を示す図である。 実施例２に係るファイルサーバの構成を示すブロック図である。 ＦＳＩＦのフック制御について説明するための図である。 fshook_task構造体の概念図である。 実施例２に係るファイルサーバの処理の流れを示すシーケンス図である。 実施例２に係るファイルサーバのＡＣＬ継承処理の流れを示すフローチャートである。 実施例２に係るファイルサーバのＮＴ−ＡＣＬ評価処理の流れを示すフローチャートである。 アクセス制御プログラムを実行するコンピュータシステムの例を示す図である。

符号の説明

１０ ファイルサーバ
１１ ｓｍｂｄ
１２ ｎｆｓｄ
１３ ＶＦＳ
１４ アクセス制御情報ＤＢ
１５ 第一アクセス制御部
１６ 第二アクセス制御部
１７ ファイルシステム
５１ ｓｍｂｄ
５２ ＶＦＳ
５３ ｐｒｏｃｆｓ
５４ ｆｓｈｏｏｋ
５５ ｓｂｌｏｃｋ／ｉｎｏｄｅ制御部
５６ ｐｒｏｃｆｓ制御部
５７ ｔａｓｋ制御部
５８ ｘａｔｔｒ制御部
５９ ｅｘｔ３／ｊｂｄ
１００ コンピュータシステム
１０１ ＲＡＭ
１０２ ＨＤＤ
１０２ａ アクセス制御制御テーブル
１０３ ＲＯＭ
１０３ａ アクセス対応プログラム
１０３ｂ 第一アクセス制御プログラム
１０３ｃ 第二アクセス制御プログラム
１０４ ＣＰＵ
１０４ａ アクセス対応プロセス
１０４ｂ 第一アクセス制御プロセス
１０４ｃ 第二アクセス制御プロセス

Claims (7)

1. 利用者端末とＣＩＦＳまたはＮＦＳで接続され、前記利用者端末からファイルシステムへのアクセス要求を受信して、当該アクセス要求を許可するか否かを判定することをコンピュータに実行させるアクセス制御プログラムであって、
   前記コンピュータは、
   前記ＣＩＦＳで使用されるアクセス権限で規定されるアクセス制御情報であって、前記ファイルシステムの各オブジェクトに対してアクセス要求を許可するか拒否するかを示す複数の構成要素を含むアクセス制御情報を記憶するアクセス制御情報記憶部を有し、
   前記コンピュータに、
   前記アクセス制御情報記憶部が記憶する複数の構成要素各々を、前記ＮＦＳで使用されるアクセス要求の基本権限に対応付ける対応付け手順と、
   前記ＣＩＦＳで接続される利用者端末から受け付けたアクセス要求に対して対応付けられた基本権限が、前記対応付け手順によって基本権限に対応付けられた構成要素の一つ以上に許可されていた場合に、当該基本権限を許可すると判定し、前記基本権限に対応付けられた構成要素の全てに拒否されていた場合に、当該基本権限を拒否すると判定する第一のアクセス制御手順と、
   前記第一のアクセス制御手順により許可された基本権限の元のアクセス要求に対して、前記アクセス制御情報記憶部に記憶されるアクセス制御情報を参照し、当該アクセス要求を許可するか否かを判定する第二のアクセス制御手順と、
   を実行させることを特徴とするアクセス制御プログラム。
2. 前記アクセス制御情報記憶部は、前記ファイルシステム上の各オブジェクトに関する情報を記憶するｉｎｏｄｅの拡張属性領域に、前記アクセス制御情報を記憶することを特徴とする請求項１に記載のアクセス制御プログラム。
3. 利用者端末とＣＩＦＳまたはＮＦＳで接続され、前記利用者端末からファイルシステムへのアクセス要求を受信して、当該アクセス要求を許可するか否かを判定することをコンピュータに実行させるアクセス制御プログラムであって、
   前記ＣＩＦＳで接続される利用者端末からファイル作成要求を受け付けた場合に、当該ファイル作成要求に応答してファイル作成を行うシステムコールを発行する前に、前記ファイルシステムの各オブジェクトに対してアクセス要求を許可するか拒否するかを示す当該ファイル用のアクセス制御情報を、当該システムコールとは異なるＩＯコントロールを介して発行するアクセス制御情報発行手順と、
   前記アクセス制御情報発行手順によりＩＯコントロールを介して発行されたアクセス制御情報を、前記ファイルシステム上のｉｎｏｄｅの拡張属性領域に格納する格納処理を実行するのに際して、前記ファイルシステムで実施される各メタデータ更新処理のための各ジャーナルと同一ジャーナルセッションで括って、前記格納処理を実行する格納処理手順と、
   前記ＣＩＦＳで接続される利用者端末からアクセス要求を受け付けた場合に、前記格納処理手順によってファイルシステムに格納されたアクセス制御情報に基づいて、当該アクセス要求を許可するか否かを判定するアクセス制御手順と、
   をコンピュータに実行させることを特徴とするアクセス制御プログラム。
4. 前記ＣＩＦＳで接続される利用者端末からアクセスされるファイルシステムのボリュームに関して、前記ファイルシステムのルートディレクトリおよびメタデータに関するインターフェースをフックし、当該マウント先のディレクトリに関するインターフェースをフックするのに際して、当該ディレクトリ直下のファイルに関するインターフェースをフックすることで、前記マウントされたボリュームに関するファイルシステムインターフェースを過不足なくフックするフック制御手順をさらにコンピュータに実行させることを特徴とする請求項３に記載のアクセス制御プログラム。
5. 前記フック制御手順は、前記ＣＩＦＳで接続される利用者端末からアクセスされるファイルシステムのボリュームに関して、当該ボリュームをマウントするマウント要求に含まれるマウントオプションにフック対象であることを示す識別子が付加されている場合にのみ、当該ボリュームがフック対象であると判定することを特徴とする請求項４に記載のアクセス制御プログラム。
6. 前記フック制御手順は、フック中のボリューム数をフックドライバ内部でカウントし、このカウントが残るうちは、ドライバのアンロードを禁止することを特徴とする請求項４または５に記載のアクセス制御プログラム。
7. 前記格納処理手順は、前記アクセス制御情報をファイルシステム上のｉｎｏｄｅの拡張属性領域に格納する場合に、前記ＩＯコントロールにおいて、当該アクセス制御情報と共にコンテキストをカーネル内フックドライバに一時的に格納し、前記システムコールにおいて、当該コンテキストが一致しているかを判定し、当該アクセス制御情報が前記アクセス制御情報発行手順により受け付けられた正当なアクセス制御情報であることを条件として、前記拡張属性領域に格納することを特徴とする請求項３〜６のいずれか一つに記載のアクセス制御プログラム。

Images