JP2012520496A - 分散ファイルシステムのアクセス - Google Patents

Abstract

【課題】
分散ファイルシステムにおいてファイルシステムオブジェクトにアクセスを提供するための方法およびシステムを提供する。
【解決手段】
分散ファイルシステム（ＤＦＳ）においてファイルシステムオブジェクトにアクセスを提供するためのシステムおよび方法を説明する。一つの実装では、ＤＦＳにおけるファイルシステムオブジェクトへのアクセスは、権限のあるユーザーおよびクライアントデバイスのみに制限することが可能である。このために、ＤＦＳの前記クライアントデバイスは信頼されているおよび非信頼クライアントに分けられ、非信頼クライアントはさらなるアクセスを拒否され得る。信頼されているクライアントを手に入れるためトラステッドコンピューティングの概念が利用できる。前記システムに追加された新しいクライアントは非信頼クライアントとして追加され得る。また、アクセスは、非信頼クライアントのアクセスをコントロールできる追加のビットを含むようファイルアクセス許可を拡張することにより、制限できる。ある状況では、前記オブジェクトの前記オーナーは前記オブジェクトに非信頼クライアントからアクセスを許可され得る。
【選択図】 図５

Description

本発明は、分散ファイルシステムにおけるファイルシステム・オブジェクトへのアクセスを提供するための方法およびシステムに関する。

ファイルシステムは典型的には、データの記憶、階層的組織、操作、ナビゲーション、アクセス、および読み出しのためのデータベースである。ファイルシステムの一種である、分散ファイルシステム（ＤＦＳ）は、ここ数十年でますます広まってきている。ＤＦＳは、名称が示すように、一つのファイルシステムがいくつかの物理的なコンピューティング・デバイスにわたり分散することができるネットワーク・ファイルシステムであり、そのコンピューティング・デバイスは、そのファイルシステム全体の一部に直接アクセスすることができる。ＤＦＳは、一般的に透過的（transparent）なレプリケーション（replication）およびフォールトトレランス（fault tolerance）のための機能が含まれている。つまり、ファイルシステムの限られた数のノードがオフラインになっても、データロスすることなくそのシステムは稼働し続ける。そのため、ＤＦＳは、組織、企業その他におけるローカル・エリア・ネットワーク（ＬＡＮ）のための非常に人気のある選択肢となっている。

典型的なコンピュータ・オペレーティング・システムでは、ファイルはアクセス許可を関連付けて保存され、十分なアクセス許可を有しているユーザーがそのファイルにアクセスを許可される。従来、ファイルアクセス許可は３つのレベルで与えられている（すなわち、オーナー、グループ、およびその他のユーザー）。それぞれのレベルはそれぞれ独自の許可基準を有することができ、ユーザーは自分のレベルのアクセス許可によって、アクセスを許可される。また、たいていのファイルシステムにおいて、それぞれのファイルは関連するオーナー識別子（ＩＤ）（すなわち、そのファイルシステム・オブジェクトを作成したユーザーのＩＤ）、およびグループＩＤ（すなわち、オーナーは一つ以上のグループの一員になり得る）を有する。現行のファイルアクセス許可は、多数のユーザーが同じマシンからファイルにアクセスできる、ローカルファイルシステムにおいてはセキュリティー侵害の可能性を（大幅に）減らすが、分散ファイルシステム下においては、そのファイルアクセス許可は脆弱性を招来する可能性がある。

ＤＦＳでは、違うコンピューティング・デバイス上から多数のユーザーが単一のファイルシステム・オブジェクトにアクセスできる。そのため、ＤＦＳでは、ファイルアクセス許可が問題を引き起こす。それらの問題は、ＤＦＳにおいては、システム内のすべてのコンピューティングデバイス上で、ユーザーＩＤが固有であるとは限らないことから起こる。例えば、２つのユーザー（ユーザーＡおよびユーザーＢのような）は、違うクライアントデバイス上で、同じユーザーＩＤ（ＩＤ１０００のような）を持つことができる。そのため、ユーザーＡが、ユーザーＢによって作成されたファイルにアクセスしようと試みるとき、ユーザーＡは、ユーザーＡがそのファイルを作成していないのにも関わらず、そのファイルにアクセスを許可されることになる（そのファイルのオーナーアクセス許可に基づき）。そのシステムは、ファイルアクセス許可がただユーザーＩＤを認識するのみなので、このアクションを許可し、また両方のユーザーが同じユーザーＩＤを持っているため、ユーザーＡおよびユーザーＢが両方そのファイルのオーナーと認識される。そのため簡単に真のユーザーのふりをすることができ、深刻なセキュリティーの脅威となりえる。

ＤＦＳの複数のセキュリティーの問題を克服する様々な方法が提案されてきた。ユーザーＩＤおよびグループＩＤをセントラル・レポジトリに集中させ、２人のユーザーが同じユーザーＩＤを持たないようにする方法がある。ユーザーがファイルオブジェクトにアクセスを要求する度に、ユーザーの認証情報がそのレポジトリと照合される。しかし、それでもセントラル・レポジトリを迂回し、ＬＡＮ上にクライアント・デバイスを導入することは可能である。また、ユーザーはその新しく導入されたクライアント・デバイス上で、ユーザーＩＤを偽造することも可能である。その上、すべてのユーザーＩＤが中央のサーバーに保存されているので、そのセントラル・レポジトリがクラッシュ(crash)すると、システム全体がクラッシュする。

公開鍵と秘密鍵の使用を伴う他の方法もある。これらの方法も、暗号鍵と共にセントラル・レポジトリを使用する。ユーザーがセントラル・レポジトリによって認証されたら、暗号鍵を要する追加のセキュリティレベルが追加される。ユーザーがその鍵を持っていなかったら、アクセスは拒否される。これらのシステムはとても複雑になりえるし、アドミニストレータの広範な教育が必要となる。その上、この分野の他の方法と同様、この方法も単一障害点(single point of failure)がある。

本発明の実施例は、分散ファイルシステムにおけるファイルシステム・オブジェクトへのアクセスを提供するための方法およびシステムを説明している。

第１の側面では、本発明は、分散ファイルシステムにおけるアクセスを提供するための方法を提供し、その方法は、アクセスを要求しているユーザーのユーザー識別子（ＩＤ）およびクライアントＩＤを読み出すこと、そのクライアントＩＤが少なくとも信頼されている（trusted）クライアントまたは非信頼（non−trusted）クライアントの内の一つに対応するものであるか判断すること、ファイルシステム・オブジェクトの拡張アクセス許可を入手することであって、その拡張アクセス許可はそのファイルシステム・オブジェクトが信頼されているクライアント上で作成されたかおよびそのファイルシステム・オブジェクトに非信頼クライアントがアクセスできるか示すことと、ユーザーＩＤ、クライアントＩＤ、およびファイルシステムオブジェクトの拡張アクセス許可に基づきそのファイルシステム・オブジェクトにアクセスを許可すること、を含む。

第１の実施例において、分散ファイルシステム（ＤＦＳ）におけるアクセスを提供するための方法を説明する。その方法は、アクセスを要求しているユーザーのユーザー識別子（ＩＤ）およびクライアントＩＤを読み出すこと、そのクライアントＩＤが少なくとも信頼されているクライアントまたは非信頼クライアントに対応するものであるか判断するステップを含む。またこの方法は、さらにファイルシステム・オブジェクトの拡張アクセス許可を入手することおよびユーザーＩＤ、クライアントＩＤ、およびファイルシステム・オブジェクトの拡張アクセス許可に基づきファイルシステム・オブジェクトにアクセスを許可することも含む。オブジェクトの拡張アクセス許可は、そのファイルシステム・オブジェクトが信頼されているクライアント上で作成されたかを示すTビット、およびそのファイルシステム・オブジェクトに、アクセスを要求しているユーザーが非信頼クライアント上からアクセスを許可されるか示すLビット、を含むことができる。

ここで信頼されているクライアントを参照している例は、トラステッド・コンピューティング・グループ（Trusted Computing Group）によって定義された方針に従って活動しているとしても、それは必須ではない。特定のクライアントが、ある一定の振る舞いをすることが知られているため「トラステッド」と識別されうる。例えば、あるソフトウェアを導入しているまたは特定のタイプのハードウェアを使用している、といったことでもあり得る。

第２の側面によると、分散ファイルシステムにおけるアクセスを提供するためのシステムを提供し、そのシステムは、ファイルシステム・オブジェクトを保存するためのメモリと、アクセスを要求しているユーザーＩＤおよびクライアントＩＤを読み出し、そのクライアントＩＤが信頼されているクライアントまたは非信頼クライアントに対応するものであるか判断し、ファイルシステム・オブジェクトの拡張アクセス許可を入手するためであって、その拡張アクセス許可はそのファイルシステム・オブジェクトが信頼されているクライアント上で作成されたかおよびそのファイルシステム・オブジェクトに非信頼クライアントがアクセスできるか示し、およびユーザーＩＤ、クライアントＩＤ、およびファイルシステム・オブジェクトの拡張アクセス許可に基づきそのファイルシステム・オブジェクトにアクセスを許可するための、処理装置が含まれる。

第２の実施例においてＤＦＳにおけるアクセスを提供するためのシステムを説明する。このシステムは、アクセスを要求しているユーザーＩＤおよびクライアントＩＤを読み出すため、およびそのクライアントＩＤが信頼されているクライアントまたは非信頼クライアントに対応するものであるか判断するための、動作可能なように組み合わされたメモリ及び処理装置を含む。さらに、該システムは、ファイルシステムのオブジェクトの拡張アクセス許可を取得するものであって、その拡張アクセス許可は、そのファイルシステム・オブジェクトが信頼されているクライアント上で作成されたか示すＴビット、およびそのファイルシステム・オブジェクトにアクセスを要求しているユーザーが非信頼クライアントからアクセスできるか示すＬビットも含むことができる。さらに、そのシステムは、ユーザーＩＤ、クライアントＩＤ、およびファイルシステム・オブジェクトの拡張アクセス許可に基づき、そのファイルシステム・オブジェクトにアクセスを許可する。

プログラムがコンピュータ上で稼働しているとき、第１の側面の方法を実行するように対応されたコンピュータプログラム手段を提供する、コンピュータプログラムも提供される。

本発明の実施例は、ほんの一例として、以下の図面を参照しつつ説明される。

図１は、一つの実施例に従い、特許請求された発明が動作しうる、例示的な分散ファイルシステム（ＤＦＳ）を図解するブロック図である。 図２は、特許請求された発明のいくつかの実施例の、バーチャルファイルシステムのブロック図である。 図３は、特許請求された発明のいくつかの実施例に従った、例示的な拡張アクセス許可を図解している。 図４は、ユーザーが、ファイルシステム・オブジェクトにアクセスを許可されるかまたは拒否されるかの、例示的シナリオを図解している図である。 図５は、本発明のある実施例に従い、分散ファイルシステムのファイルシステム・オブジェクトへ、アクセスを提供するための方法のフローチャートである。 図６は、本発明のある実施例に従い、分散ファイルシステムのファイルシステム・オブジェクトへ、アクセスさせるか判断するための方法のフローチャートである。

以下の詳細な説明は、数字を参照しつつ行われる。好適な実施例は、特許請求された発明の範囲を限定するためでなく、説明するために記載され、特許請求された発明は、特許請求の範囲に記載される。当業者は、以下の説明の様々な均等物に気づくであろう。

特許請求された発明のある実施例は、分散ファイルシステム（ＤＦＳ）におけるアクセスを提供するための方法を説明する。その方法により、真正のユーザーがファイルシステム・オブジェクトにアクセスできる。さらに、この方法により、真正のクライアント・デバイスからファイルシステム・オブジェクトにアクセスできる。特許請求された発明の別の実施例は、唯一固有のユーザーを認識するため、ユーザー識別子（ＩＤ）およびクライアントＩＤの組み合わせを使用する。また、トラステッド・コンピューティング（trusted computing）の概念が、開示されたソリューションで利用されている。一つの実施例で、ファイルシステムのアクセス許可は、分散ファイルシステムにおけるオブジェクトのセキュリティーを強化するために、拡張されうる。

図１は、好適な実施例に従い、特許請求された発明が動作しうる、例示的な分散ファイルシステム（ＤＦＳ）１００を図解するブロック図である。ＤＦＳ１００は、一つ以上のファイルシステム・サーバーコンピューティングデバイス１０４−Ａ、１０４−Ｂ（ファイルシステム・サーバー１０４）、一つ以上のクライアントコンピューティングデバイス１０６−Ａ、１０６−Ｂ、１０６−Ｃ、および１０６−Ｄ（クライアント１０６）、並びにセントラル・レポジトリ１０８をつなぐ、ネットワーク１０２を含む。さらに、一人以上のユーザー１１０−Ａ、１１０−Ｂ、１１０−Ｃおよび１１０−Ｄ（ユーザー１１０）が、ネットワーク１０２を通じて、クライアント１０６から、ファイルシステム・サーバー１０４に保存されているオブジェクトにアクセスすることができる。ファイルシステム・オブジェクトは、ファイル、ディレクトリー、フォルダ、ドキュメント、およびデジタルメディア上に通常保存される他の類似のオブジェクトを含み得る。

ＤＦＳ１００において、様々なファイルシステムが複数のファイルシステム・サーバー１０４にわたって分布することができ、違った地理的位置にあってもよいが、一つのルートＤＦＳフォルダの下で論理的に対応づけられる。そのため、ユーザー１１０はファイルシステム・サーバー１０４の正確な位置を知る必要がない。さらに、ＤＦＳ１００は、トランスペアレントなレプリケーションおよびフォールトトレランスのための機能を含むことができるため、ファイルシステム・サーバー１０４の限られた数がオフラインになっても、データロスすることなくそのシステムは稼働し続ける。

ネットワーク１０２は当該技術分野に知られたいかなる有線または無線のネットワークでもよい。例えば、そのネットワークはローカル・エリア・ネットワーク（ＬＡＮ）、メトロポリタン・エリア・ネットワーク（ＭＡＮ）、インターネットなどである。一つの実施例において、ネットワーク１０２は、例えば、複数のオフィスのＰＣ、様々なサーバー、いくつかの国にわたって広がっているその他のコンピューティングベースのデバイスを接続する、会社のネットワークのような、プライべートネットワークである。あるいは、ネットワーク１０２は、無線ＬＡＮ（ＷＬＡＮ）を介して接続している、一つの家族に属する限られた数のＰＣによるホームネットワークも含む。他の実施例においては、ネットワーク１０２は、中小企業における限られた数のクライアントを接続することができる。当然のことながら、ネットワークのタイプは本発明の範囲を制限するものでなく、いかなる既知のネットワーク形態をもＤＦＳ１００を実行するのに使用できる。

さらに、ＤＦＳ１００はＩＢＭ（登録商標）ＡＩＸ（登録商標）オペレーティング・システム、Solaris（登録商標）ファイルシステム、Ｌｉｎｕｘ（登録商標）ファイルシステム、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）オペレーティング・システム、ＭＡＣオペレーティング・システムのような、当該技術分野におけるあらゆる既知のオペレーティング・システム上で機能し得る。特許請求された発明の実施例は、ＵＮＩＸ（登録商標）オペレーティング・システムに関して説明されているが、その代わりに当該技術分野におけるあらゆる既知のオペレーティング・システムが利用できる。（ＩＢＭおよびＡＩＸは米国およびその他の国におけるInternationalBusiness Machines Corporationの商標；ＭｉｃｒｏｓｏｆｔおよびＷｉｎｄｏｗｓは米国およびその他の国におけるＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎの商標；Ｌｉｎｕｘは、米国およびその他の国におけるＬｉｎｕｓ Ｔｏｒｖｏｌｄｓの登録商標；ＵＮＩＸは、米国およびその他の国におけるＴｈｅ Ｏｐｅｎ Ｇｒｏｕｐの登録商標；他の製品名およびサービス名はＩＢＭまたは他の会社の商標である場合がある。）

さらに、ファイルシステム・サーバー１０４およびクライアント１０６は、メモリ、処理装置、入出力ポート、ネットワーキングポートなどを備えることができる。図１において、ファイルシステム・サーバー１０４−Ａは、メモリ１１２および処理装置１１４と共に描かれている。処理装置１１４は、マイクロプロセッサー、マイクロコンピュータ、マイクロコントローラー、デジタル・シグナル・プロセッサ、中央処理装置、状態機械、論理回路、および／または、操作命令に基づき信号を操作するあらゆるデバイスを含み得る。数ある能力の中で、処理装置１１４は、メモリ１１２に保存されたコンピュータ可読命令を、フェッチ(fetch)し実行するよう、構成されている。メモリ１１２は、例えば、揮発性メモリ（例、ＲＡＭ）、および／または非揮発性メモリ（例、フラッシュなど）を含む、当技術分野で周知のあらゆるコンピュータ可読媒体を含み得る。メモリ１１２および処理装置１１４はあらゆる物理的実装ができ、特定のデバイス実装に応じ動作可能なように組み合わせることができる。これらのコンポーネントは、例えば図２から図６に関して図解的に説明されている、この明細書の説明に従った方法を実行するよう、適合され、配置され、構成され、および設計されることができる。クライアント１０６およびファイルシステム・サーバー１０４のそれぞれがメモリおよび処理装置を装備し得ることは、当業者にとって明らかであろう。

さらに、特許請求された発明の実施例は、権限のないクライアント（ＤＦＳ１００によって認識されていないクライアント）上のユーザーのアクセスを制限し、権限のないクライアント上の権限あるユーザーのアクセスを許可する。この目的を達成するために、クライアント１０６のすべては、トラステッド・コンピューティングの原則に従って、２つのグループ、すなわち、信頼されているクライアントおよび非信頼クライアントに分けられる。

トラステッド・コンピューティング（ＴＣ）は、トラステッド・コンピューティング・グループによって開発され促進されてきたテクノロジーである。トラステッド・コンピューティングにより、クライアント１０６は、一貫して、ハードウェアおよびソフトウェアによって強制された、一定の振る舞いをする。強制された信頼される(trusted)振る舞いとは、ハードウェアに固有のＩＤおよび固有のマスターキーをロードし、クライアントのオーナーにですらマスターキーの情報やコントロールを拒否する、ことにより成し遂げられる。トラステッド・コンピューティングはハードウェアを、オーナーのためだけでなく、オーナーからも守り、ユーザーが権限あるユーザーになりすますことを禁ずる。ネットワーク・ファイルシステム（ＮＦＳ）、ネットワーク・インフォメーション・サービス（ＮＩＳ）、ライトウェイト・ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）、などトラステッド・コンピューティングを実装するための多くの技術が当該技術分野で知られている。あらゆる既知の技術がＴＣを実装するために使用することができる。

一つの実装では、ＮＩＳが利用できる。ＮＩＳにおいては、クライアントＩＤがセントラル・レポジトリ１０８のような、セントラル・レポジトリの中に保存される。それぞれのクライアントはサポートできるユーザーＩＤのリストを持つ。クライアントＩＤが中央で保存されているため、ＮＩＳは２つのクライアントが同じユーザーＩＤを持たないこと、そのため唯一固有のユーザーＩＤを保証している。ネットワーク１０２に導入された新しいクライアントがファイルシステム・サーバー１０４にアクセスしようと試みても、ＮＩＳがこのクライアントが唯一固有のユーザーＩＤを持っているか分からないので、非信頼クライアントとして扱われる。ＮＩＳがそのクライアントを設定して、そのクライアント上のユーザーＩＤが信頼されているクライアント上のユーザーＩＤに合うものであるとき、そのクライアントは信頼されているクライアント・グループにアップグレードされ得る。

図１は、信頼されているクライアント１１６および非信頼クライアント１１８を図示している。信頼されているクライアント１１６は、クライアント１０６−Ａ、１０６−Ｂ、および１０６−Ｃを含み、非信頼クライアント１１８は、クライアント１０６−Ｄと１０６−Ｅを含む。一つの実装では、信頼されているクライアント１１６および非信頼クライアント１１８が、ファイルシステム・サーバー１０４のメモリ１１２の中に保存されたクライアントのリストに含まれ得る。他の実装では、クライアントのリストは、セントラル・レポジトリ１０８に保存されていてよい。さらに、ネットワーク１０２の新しいクライアントは、非信頼クライアント１１８に直接追加され得る。ＮＩＳがユーザーＩＤを認証したら、クライアントは信頼されているクライアント１１６にアップグレードすることができる。

ユーザーがＤＦＳ１００上のファイルシステム・オブジェクトを要求してきたとき、ＮＩＳはクライアントのリストに照らして、そのユーザーのクライアントＩＤを照合する。そのユーザーのクライアントＩＤがクライアントのリストにないときには、ＮＩＳはユーザー１１０のアクセスを許可しない。そのユーザーのクライアントＩＤがクライアントのリストに存在するときは、ファイルシステム・サーバー１０４はユーザー１１０が正しいユーザーＩＤを提示してきたか確認する。その確認により、ユーザーＩＤが、当該ファイルシステム・オブジェクトのアクセス許可についてチェックされたことになる。

このように、特許請求された発明の実施例は、ユーザー１１０が唯一固有の識別子を持つことができること、唯一固有の識別スキームの一部でないクライアントは非信頼クライアント１１８になり得ること、を保証する。信頼されているクライアントと非信頼クライアントを分離することで、ファイルシステム・サーバー１０４は、信頼されているクライアント１１６上の真正ユーザーに、ファイルシステム・サーバー１０４にアクセスを許可し、同時に非信頼クライアント１１８上の偽ユーザーのアクセスを拒否することができる。

さらに、多くの技術が、ユーザー１１０を一意的に識別するのに利用できる。一つの実装において、ユーザーは、ユーザーＩＤおよび、ユーザーが通常操作しているクライアントに対応した、クライアントＩＤの組み合わせを使用することで識別できる。ユーザーＩＤおよびクライアントＩＤの組み合わせは、数値、英数字値、ユーザー名、ＭＡＣアドレス、ユーザー個人情報など、あらゆる形態をとり得る。他の実装では、数値、英数字値その他のようなあらゆる唯一固有のＩＤがユーザーＩＤとして考えられる。

そのため、特許請求されている発明の実施例によると、ファイルシステム・オブジェクトのアクセスはユーザーＩＤ、クライアントＩＤ、およびファイルシステム・オブジェクトのアクセス許可による。ユーザーがユーザーＩＤだけでなく、それぞれのロケーション（ユーザーが信頼されているまたは非信頼クライアント上で操作しているか）により定義されるため、従来のオブジェクトのアクセス許可は、ユーザーのロケーションに基づき違ったアクセス許可を提供するために、修正される必要がある。この目的を達成するために、特許請求されている発明の実施例は、現在のファイルシステムのアクセス許可へいくつか新しいビットを追加し、既存のアクセス許可ビットをオーバーロードしている。拡張アクセス許可の説明は図３の説明と共に提供される。

従来のアクセス許可についてのある程度の事前の知識が、本明細書で開示されているソリューションである拡張アクセス許可を理解するのに必要なため、以下のセクションでは従来のファイル・アクセス・スキームを説明する。従来のアクセス許可はＵＮＩＸオペレーティング・システムに関連して説明される。しかし、従来のアクセス許可は、当該技術分野で既知の他のあらゆるオペレーティング・システムに関連して説明することが理解されるだろう。それぞれのオペレーティング・システムは独自のシンタックス(syntax)、コマンド、ファイルネーム、などを持つが、従来のアクセス許可の基本概念は、標準的なオペレーティング・システムにおいて同じである。

ＵＮＩＸにおいて、ユーザーを識別するのにユーザーＩＤおよび少なくとも一つのグループＩＤが使用できる。また、一つのグループの中のユーザーは、一つのグループＩＤの下で分類され得る。例えば、一つの組織は、ファイナンスのチーム、人事チーム、ＩＴチーム、など様々なチームを持つことができる。ファイナンスのチームのメンバーは、ファイナンスのグループＩＤの下にグループ化することができ、人事チームのメンバーは、人事のグループＩＤの下にグループ化することができ、その他も同様である。さらに、チームのマネージャーは、エグゼクティブグループＩＤの下で組織化され得る。アドミニストレーターまたはルートユーザーがグループＩＤを管理することができる。通常は、すべてのファイルシステムのオブジェクトは、そのファイルシステム・オブジェクトを作成したオーナーのユーザーＩＤと、オーナーが所属しているグループのグループＩＤを含む。

従来のアクセス許可は、オブジェクトのオーナー、グループメンバー、または他のあらゆるユーザーのような、ユーザーの異なるレベルのための、読み込み（read）、書き込み(write)、実行(execute)のような、許可である。ＵＮＩＸは通常、３つの８進数字で表すことができる、９ビットのアクセス許可を割り当てる。８進数字はそれぞれ、オーナー、グループメンバー、または他のあらゆるユーザー、のそれぞれの許可を表している。最初の８進数字はオブジェクトのオーナーのアクセス許可、次の８進数字はオーナーが所属しているグループのメンバーに許可されたアクセス、そして最後の８進数字は他のあらゆるユーザーのためのアクセス許可を表している。さらに、８進数字のそれぞれの２進ビットは、読み込み、書き込み、実行の許可のような、個別の許可を表し得る。最初のビットは読み込み許可を示し、第２のビットは書き込み許可を示し、３番目のビットは実行許可を示す。ビット値が１の場合、許可は有効になり、他の場合は許可がブロックされる。例えば、８進数字の７は、バイナリー値で１１１なので、ユーザーはファイルシステム・オブジェクトの読み込み、書き込み、実行の許可があることを示す。

オブジェクトのオーナーまたはアドミニストレーターのような権限のあるユーザーが、通常アクセス許可を割り当てる。ある状況では、アクセス許可はプロセスまたは環境であらかじめ設定できるので、そのプロセスまたは環境で作成されたすべてのオブジェクトは、そのプロセスまたは環境に割り当てられたアクセス許可を自動的に持つ。権限のあるユーザーは、オブジェクトの作成後はいつでもオブジェクトのアクセス許可を変更することができる。

ＵＮＩＸシステムにおいて、従来のアクセス許可は、レギュラーファイル（regular file）、ディレクトリー(directory)、または他のファイルシステム・オブジェクトについての基本的な情報を保存している、iノード(inode)とよばれるメタデータファイルに保存されている。それぞれのファイルシステム・オブジェクトは、一つのiノードおよび、ファイルシステムのiノードおよびそれがどこに存在するかを特定する、一つのiノード番号(しばしばi-numberまたはinodeと言及される)を持つことができる。

通常、iノードは、オーナーのユーザーＩＤおよびグループＩＤ、アクセス許可（読み込み、書き込み、実行許可）並びに、オブジェクトのタイプ、のような、ファイルシステム・オブジェクトについての情報を保存している。さらに、iノード番号により、デバイス上の知られたロケーションに、iノードのデーブルの索引(index)をつける。iノード番号により、カーネル(kernel)はiノードの中身およびファイルシステム・オブジェクトの中身にアクセスすることができる。通常、カーネルは、特定のファイルネームを探してディレクトリーを検索し、その後ファイルネームを正しい対応するiノード番号に変換する。

ＤＦＳ１００は多数のファイルシステムを有し、ある実施例においては、ファイルシステムは、Solaris（登録商標）ファイルシステム、Ｌｉｎｕｘ（登録商標）ファイルシステム、Ｗｉｎｄｏｗｓ（登録商標）ファイルシステム、ＭＡＣ ＯＳファイルシステム、ＵＮＩＸ（登録商標）ファイルシステムその他の、違ったタイプのファイルシステムで構成されることができる。ファイルシステム・サーバー１０４のそれぞれは、ファイルシステムのオブジェクトについて独自のメタデータの保存の方法をとることができる。ユーザーが、違ったファイルシステムのオブジェクトにシームレス(seamless)にアクセスするために、バーチャルファイルシステム(VFS)の抽象化層(abstractionlayer)がＤＦＳ１００中のファイルシステム・サーバー１０４の最上層に存在することができる。

図２は、ＶＦＳ２０２およびそれと様々なファイルシステム・サーバー１０４との関係をあらわしている。ＶＦＳ２０２により、クライアント１０６が、異なるタイプのファイルシステム・サーバー１０４に、同じ方法で、アクセスが可能になる。さらにＶＦＳ２０２は、例えば、クライアント１０６がローカルおよびネットワークサーバーに、違いを意識させずに透過的に、アクセスするのに使用できる。ＶＦＳ２０２は、様々なファイルシステムにおける違いを埋めるので、クライアント１０６は、ファイルシステムのタイプを知らなくても、ファイルシステム上のオブジェクトにアクセスできる。

違ったファイルシステムのiノードを読み出すため、ＶＦＳ２０２はvノード(vnode)２０４というデータ構造を使用する。すべてファイルの操作はvノード２０４ででき、これは公開データおよびプライベートデータを含む。それぞれのvノード２０４の公開データフィールドは、ＶＦＳ２０２層でのみ操作できるデータか、ファイルのタイプのような、ファイルシステム・オブジェクトの存続期間を通じて変更がないデータを含む。それぞれのvノード２０４のプライベートデータフィールドは、ファイルシステムのiノードテーブルのような、ファイルシステムに依拠するデータを指し示す。vノード２０４はファイルシステム・サーバー１０４のiノードテーブルの値と共に描写されている。

ファイルシステムのvノード２０４は、特定のファイルシステム・サーバー１０４のファイルシステム・オブジェクトのiノード番号を指し示すことができる。そのため、ＤＦＳ１００では、オブジェクトのアクセス許可には、ファイルシステム・オブジェクトのvノードおよび／またはiノードを通じてアクセスできる。さらに、iノードのアクセス許可フィールドは通常１６ビットのフィールドである。現在、１６ビット中の９ビットはファイルシステム・オブジェクトの従来のアクセス許可を定義するために使用され、３ビットは特別目的のセキュリティのために使用され、１６ビット中４つの未使用のビットが残ることになる。

図３は、特許請求された発明の実施例に従い、例となる拡張アクセス許可３００を説明したものである。例となる拡張アクセス許可３００は、上述した従来の９ビットのアクセス許可に対し、１１ビット含む。特許請求された発明の実施例は、アクセス許可フィールド中の４つの未使用ビットのうち、２つを利用する。拡張アクセス許可３００の最初の９ビット（３つの８進数で示すことができる）は、オーナーモードビット３０２、信頼されているクライアント上のグループモードビット３０４、その他（他の人全員）モードビット３０６、を示すために使用される。また、特許請求された発明の実施例は、モードビットの定義を変更する。通常、第２番目の８進数の数字はグループメンバーのアクセス許可を表すが、特許請求された発明によると、第２番目の８進数の数字は、信頼されているクライアント１１６からオブジェクトにアクセスするグループメンバーのアクセス許可を示している。さらに、第３番目の８進数の数字３０６は、上述したその他の人の許可というより、その他の許可を示す。いくつかの実装では、その他モードビット３０６は、非信頼クライアント１１８上のオーナー、非信頼クライアント１１８上のグループメンバー、または他のユーザーをチェックできる。

１０番目および１１番目のビットは、特許請求された発明の実施例において紹介される、Ｔビット３０８およびＬビット３１０であり得る。Ｔビット３０８は、ファイルシステム・オブジェクトが、信頼されているクライアント１１６上で作成されたか非信頼クライアント１１８上で作成されたかを示す。Ｔビット３０８でステイタスが有効（すなわち、ビット値が１）はファイルシステム・オブジェクトが、信頼されているクライアント１１６上で作成されたことを示し、Ｔビット３０８でステイタスが無効（すなわち、ビット値が０）は、ファイルシステム・オブジェクトが非信頼クライアント１１８上で作成されたことを示す。一つの実装では、オブジェクトが作成されたら処理装置が自動的にＴビット３０８をセットすることができる。さらに、オーナーがオブジェクトにアクセスを許可され、オーナーが信頼されているクライアント１１６からオブジェクトを修正した場合、Ｔビット３０８は、以前に無効になっていたとしても、自動的に有効となり得る。

Ｌビット３１０は、オブジェクトのオーナーであって、非信頼クライアント１１８上のユーザーが、そのオブジェクトにアクセスを許可されるかを示す。そのため、有効Ｌビット３１０は、オーナーが非信頼クライアント１１８からアクセスを許可され、無効Ｌビット３１０はオーナーが非信頼クライアント１１８からアクセスを許可されないことを示す。このビットは、ファイルシステム・オブジェクトのオーナーが信頼されているクライアント１１６上でファイルシステム・オブジェクトを作成して、非信頼クライアント１１８のような、別のクライアントからそのファイルシステム・オブジェクトにアクセスしたい特別な状況で適用される。そのような状況では、オーナーはＬビット３１０を有効にし、オブジェクトのiノードに非信頼クライアント１１８のクライアントＩＤを追加し得る。オーナーの要求により非信頼クライアント１１８のいくつでもiノードに追加し得る。さらに、オーナーは、いかなる時でも、非信頼クライアント１１８のリストを修正し得る。

一つの実装では、オーナーモードビット３０２は、Ｔビット３０８によりオーバーロード（多重定義）されうる、それはアクセスが、ＴビットおよびＬビットの値ならびにオーナーのロケーションにより異なった状況で、オーナーモードビット３０２に基づくことができるということである。例えば、Ｔビット３０８が有効であり（ファイルシステム・オブジェクトは信頼されているクライアント１１６で作成された）オーナーがそのオブジェクトに信頼されているクライアント１１６からアクセスしようとしている場合、アクセスはオーナーモードビット３０２による。一方、オーナーが非信頼クライアント１１８からアクセスしようとした場合は、オーナーはその他モードビット３０６によりアクセスを許可される。Ｌビット３１０が有効であり、オーナーが非信頼クライアント１１８からオブジェクトにアクセスしようとした場合（そして非信頼クライアントＩＤがそのオブジェクトのiノードに存在している）、アクセスはオーナーモードビット３０２により判断される。また、ファイルシステム・オブジェクトが非信頼クライアント１１８で作成された場合（すなわち、Ｔビット３０８は無効にされている）、オブジェクトのオーナーのアクセスは、両方の場合（すなわち、信頼されている１１６または非信頼クライアント１１８から）でオーナーモードビット３０２に依拠し得る。

もしオブジェクトが非信頼クライアント１１８で作成された場合（すなわち、Ｔビットは無効にされている）、アクセスは信頼されているクライアント１１６に制限されているわけでなく、非信頼クライアント１１８上のクライアント上のユーザーも彼らのアクセスモードビットにより、そのオブジェクトにアクセスし得る。さらに、この場合、信頼されているクライアントモードビット３０４のグループは、グループモードビットとして読みこまれることができ、非信頼クライアント１１８上のグループのメンバーでさえ、これらのモードビットでアクセスできる。

ユーザー１１０のアクセスはユーザーＩＤだけでなく、クライアントＩＤにも依拠するので、アクセス許可はユーザー１１０について動的に変わり得る。それに応じて、クライアントＩＤ、ユーザーＩＤ、拡張アクセス許可３００のＴビット３０８およびＬビット３１０に基づき、オブジェクトの実際効力を有するアクセス許可は変わり得る。例えば、クライアント１０６−Ａ上のユーザー１１０―Ａは、アクセス許可７５５で「confidential.txt」ファイルを所有している。もしユーザー１１０―Ａが、クライアント１０６−Ｄのような、非信頼クライアント１１８からそのファイルにアクセスしようとすると、オブジェクトのアクセス許可は４４４に動的に変化し得る。

図４を見ると、ユーザーがファイルシステム・オブジェクトへのアクセスを許可されたり拒否されたりするいくつかのシナリオを図解している。図４は、信頼されているクライアント１１６および非信頼クライアント１１８を含むシステム４００を表現している。さらに信頼されているクライアント１１６のそれぞれおよび非信頼クライアント１１８のそれぞれは、ファイルシステム・サーバー１０４−Ａのような、例示的なファイルシステム・サーバーと接続されている。異なったシナリオをさらに説明するために、例示的ファイルシステム・オブジェクトが使用されている。例えば、ファイルシステム・オブジェクト「confidential.txt」が、ファイルシステム・サーバー１０４−Ａ上に存在する。そのオブジェクトの拡張アクセス許可３００は以下例１に表現される（図３に関連して説明されるように）。

例１：ファイルシステム・オブジェクトの拡張アクセス許可３００-confidential.txt

例１の拡張アクセス許可３００は信頼されているクライアントのオーナーは完全な許可を持ち（１１１）、信頼されているクライアントのグループのユーザーは読み込みと実行の許可を持ち（１０１）、およびその他は許可がない（０００）ことを示す。さらに、拡張アクセス許可３００は、そのファイルが信頼されているクライアント上で作成されたこと（Ｔビット３０８が有効）、およびオーナーが非信頼クライアント１１８からアクセスできること（Ｌビット３１０が有効）を示す。ファイルシステム・オブジェクトconfidential.txtにアクセスを要求しているユーザーは、オブジェクトのオーナー、オーナーグループのメンバー、またはその他のユーザーであり得る。ユーザーが信頼されているクライアント１１６からオブジェクトにアクセスしようとするとき、アクセスはユーザーのタイプによる。例えば、ユーザーがオーナー４０２であるとき、アクセスはオーナーモードビット３０２により、オーナー４０２はファイルの完全なアクセスを許可される。ユーザーがグループ４０４に属しているとき、信頼されているクライアント上のグループモードビット３０４がアクセスされ、ユーザーはファイルを読み込みおよび実行することを許可される。ユーザーがその他ユーザー４０６であるとき、アクセスはその他モードビット３０６により、ユーザーはファイルにアクセスを許可されない。

今度は別のシナリオで、ユーザーがファイル「confidential.txt」に非信頼クライアント１１８からアクセスしようとしたとき、いくつかの結果があり得る。ユーザーがオーナー４０２であるとき、２つの状況が起こりえる。最初の状況では、オブジェクトのiノードの中に非信頼クライアントＩＤが保存されていて、その場合、アクセスはオーナーモードビット３０２に基づき、そしてオーナー４０２はアクセスを許可される。第２の状況で、非信頼クライアント１１８のためのＩＤがオブジェクトのiノードの中に保存されていなく、その場合アクセスはその他モードビット３０６に基づき、そしてオーナー４０２はアクセスを許可されない。今の例によると、Ｌビット３１０は有効だが、Ｌビット３１０が無効にされたら、アクセスはその他モードビット３０６に基づくことになり、オーナー４０２はアクセスを許可されない。

ユーザーがグループ４０４に属しているとき、アクセスはその他モードビット３０６に基づき、ユーザーはファイルにアクセスを許可されない。最後に、ユーザーがその他ユーザー４０６であるとき、アクセスはその他モードビット３０６に基づき、ユーザーはファイルにアクセスを許可されない、なぜならその他モードビット３０６が０００だからである。

また、その他の例として、ファイルシステム・オブジェクト「salary.txt」が以下例２に表現されているように、拡張アクセス許可３００を有すことができる。

例２：ファイルシステム・オブジェクトの拡張アクセス許可３００-salary.txt

例２で示された拡張アクセス許可３００は、オーナー４０２が非信頼クライアント１１８上でファイルを作成した（Ｔビット３０８が無効（０）であるため）ことを示している。この場合、すべてのユーザーが、たとえ非信頼クライアント１１８上であっても、あたかも信頼されているクライアント１１６上に存在するかのように扱われ、アクセスは最初の９ビットのアクセス許可に基づく。しかし、もしオーナー４０２が信頼されているクライアント１１６からファイルを上書き／差し替えると、Ｔビット３０８は自動的に１にセットされ（有効）、ファイルはあたかも信頼されているクライアント１１６上で作成されたかのように扱われる。

図５は、図１から４を参照してＤＦＳ１００の中でアクセスを提供するための例示的方法５００を図解している。方法５００はＤＦＳ１００の中で要求されたファイルシステム・オブジェクトへのアクセスを許可するためのステップを含む。さらに方法５００は、ユーザーＩＤおよびクライアントＩＤを読みだし、クライアントが信頼されているクライアントか判断し、オブジェクトの拡張アクセス許可３００を探索し、ユーザーのタイプを判断し、ならびに拡張アクセス許可３００およびユーザーのロケーションに基づきアクセスを提供する、ステップを含む。

ステップ５０２において、方法５００は、アクセス要求しているユーザーのユーザーＩＤおよびクライアントＩＤを読み出す。要求しているユーザーは、ファイルシステム・サーバー１０４の内の一つにあるファイルシステム・オブジェクトへのアクセスを要求しているユーザー１１０であり得る。一つの実施態様では、ファイルシステム・サーバー１０４はクライアント１０６のクライアントＩＤを読み出し、そのクライアントＩＤを、セントラル・レポジトリ１０８またはメモリ１１２に存在するクライアントのリストと比較することができる。他の実施態様では、ファイルシステム・サーバー１０４はＮＩＳを利用してクライアントおよびクライアントＩＤのリストを読み出すことができる。クライアントＩＤがクライアントＩＤのリストの中に存在するなら、ＮＩＳまたはファイルシステム・サーバー１０４がユーザーの識別をチェックするのに進む。ユーザーＩＤがクライアントＩＤと共に存在したなら、ユーザーは本物であると証明される；そうでない場合はユーザーが本物であることを証明されない。一つの実装では、ユーザーＩＤはユーザーＩＤおよびクライアントＩＤの組み合わせからとられた唯一固有の値であり得る。他の実装では、ユーザーＩＤはあらゆる唯一固有の値であり得る。

ステップ５０４で、方法５００は、クライアントＩＤが信頼されているクライアントまたは非信頼クライアントに対応するか判断することができる。一つの実装では、ファイルシステム・サーバー１０４はクライアントＩＤを、セントラル・レポジトリ１０８またはメモリ１１２に保存された信頼されているクライアントのリストと比較することができる。クライアントＩＤが信頼されているクライアントの中に存在したら、クライアントは信頼されているクライアントである；そうでないなら、クライアントは非信頼クライアントである。トラステッド・コンピューティングは信頼されているクライアント１１６および非信頼クライアント１１８のリストを維持できる。例えば、ＮＩＳは、クライアントＩＤが信頼されているまたは非信頼クライアントに対応するかを判断するのに利用できる。

クライアントが信頼されているクライアントまたは非信頼クライアントか判断すると、方法５００は、ステップ５０６でファイルシステム・オブジェクトの拡張アクセス許可を探索することができる。一つの実装では、ファイルシステム・サーバー１０４の処理装置１１４が、ファイルシステム・オブジェクトのｖノード２０４から拡張アクセス許可３００を取得することができる。他の実装では、拡張アクセス許可３００はオブジェクトのiノードから取得することができる。

拡張アクセス許可３００を取得したら、ステップ５０８において処理装置１１４はユーザータイプを判断することができる。一つの実装においては、処理装置１１４は、オーナー、信頼されているクライアント上のグループメンバー、他のユーザー、非信頼クライアント上のオーナー、または非信頼クライアント上のグループメンバーを含むリストから、ユーザータイプを判断することができる。ファイルシステム・サーバー１０４は、ユーザーＩＤ、クライアントＩＤ、およびオブジェクトのオーナー情報に基づいて判断をすることができる。例えば、もしユーザーＩＤがオブジェクトのiノード中のオーナーＩＤと合致して、およびクライアントＩＤが信頼されているクライアント１１６に対応していたら、ファイルシステム・サーバーはそのユーザーが信頼されているクライアント上のオーナーと判断できる。他の例で、もしユーザーＩＤがそのファイルシステム・オブジェクトのオーナーＩＤまたはグループＩＤと合致しなかったら、ファイルシステム・サーバー１０４はアクセスを要求しているユーザーはその他のユーザーと判断できる。

ステップ５１０で、ファイルシステム・サーバー１０４は、ユーザーＩＤ、クライアントＩＤ、および拡張アクセス許可に基づき、ユーザーに対しアクセスを許可しまたは拒否し得る。一つの実装では、ファイルシステム・サーバーは、ファイルシステム・オブジェクトが信頼されているクライアント１１６上で作成されたか、およびユーザーが非信頼クライアント１１８からそのファイルシステム・オブジェクトにアクセスできるかチェックする。一つの実装では、ファイルシステム・サーバー１０４上の処理装置１１４が、ファイルシステム・オブジェクトが信頼されているクライアント１１６上で作成されたか、および非信頼クライアント１１８上のユーザーがそのオブジェクトにアクセスできるか判断するため、拡張アクセス許可３００のＴ３０８およびＬビット３１０をチェックすることができる。その判断に基づき、そのオブジェクトの有効なアクセス許可を取得することができる。処理装置１１４は、ユーザーのタイプおよび拡張アクセス許可３００に基づき（図３と関連して説明されているように）、オブジェクトのアクセス要求があるたびに、そのオブジェクトについて有効なアクセス許可を評価することができる。例えば、ユーザーのタイプが信頼されているクライアントのグループの場合、ファイルシステム・サーバー１０４は、信頼されているクライアント上のグループモードビット３０４に基づき、オブジェクトへのアクセスを提供することができる。アクセスは、一連のアクセスルールに基づき提供されるが、それは図６に関連して詳細に説明される。

もしステップ５１０のアウトプットで、アクセスを要求しているユーザーがファイルシステム・オブジェクトにアクセスを許可される場合、ファイルシステム・オブジェクトは読み出されクライアント１０６に提示される。一つの実装では、ファイルシステム・サーバー１０４上のオブジェクトのロケーションを判断するため、ファイルシステム・オブジェクトのiノード番号をチェックすることができる。他の実装では、ＤＦＳ１００中のオブジェクトのロケーションを判断するため、ファイルシステム・オブジェクトのｖノード２０４をチェックすることができる。さらに、アクセスを要求しているユーザーは、彼／彼女に付随するアクセスモードビットによって定義されたようにアクセスを許可される。例えば、もしユーザー１１０が読み込み許可のみ有しているのであれば、ユーザー１１０はオブジェクトの書き込み、修正または実行をできない。

図６は、ユーザーがアクセスを認められるべきか判断するための、例示的方法６００を説明するフローチャートである。方法６００は、アクセス可能性を判断するため、ユーザーＩＤおよびクライアントＩＤとアクセス許可を比較することを含む。

ステップ６０２において、方法６００はクライアントが信頼されているクライアント１１６かどうか判断する。一つの実装において、ＮＩＳが、クライアントＩＤが信頼されているクライアントＩＤと合致するかどうかチェックすることができる。信頼されているクライアント１１６のリストは、セントラル・レポジトリ１０８またはファイルシステム・サーバー１０４から取得することができる。一つの実装では、処理装置１１４も、アクセスを要求しているユーザー１１０のユーザーＩＤが、クライアントのメモリに通常保存されているユーザーＩＤのリスト中に存在するか確認することができる。ある場合には、ユーザーＩＤがクライアントＩＤのリストと共に、セントラル・レポジトリ１０８またはメモリ１１２に保存することもできる。

もしクライアントが信頼されているクライアント１１６であるなら（ステップ６０２から「はい」方向）、サーバーの処理装置１１４はユーザーがルート・ユーザー（root user）かチェックし（ステップ６０４）、もしそうでなければ、処理装置１１４はステップ６０６においてユーザーＩＤがオーナーＩＤに対応するものであるかチェックするのに進む。

ステップ６０４において、本件方法は、ユーザーがルートユーザーか判断する。ルートユーザーはアドミニストレーター（管理者）またはセキュリティアドバイザーであり得る。ルートユーザーは通常ＤＦＳ１００中のすべてのアクセス許可を有している。もしユーザー１１０がルートユーザーなら、方法６００はステップ６１８に移動し、ユーザー１１０は、そのオブジェクトの拡張アクセス許可３００に関係なく、ファイルシステム・オブジェクトへのアクセスが許可される。処理装置１１４は、ユーザーＩＤに基づきユーザー１１０がルートユーザーかどうか判断できる。

もしユーザー１１０がルートユーザーでない場合、ステップ６０８において処理装置１１４は、ユーザー１１０がオーナー４０２であるかどうかチェックすることができる。一つの実装では、ユーザーＩＤがオブジェクトのオーナーＩＤと照合され得る。一つの実装ではオーナーＩＤはオブジェクトのiノード／vノードから取得され得る。もしそれらのＩＤが合致したら、ユーザー１１０はオブジェクトのオーナー４０２であると判断され得る。ユーザーがオーナー４０２の場合（ステップ６０８から「はい」方向）、処理装置１１４は、ステップ６１２において、オーナーモードビット３０２を参照することができる。

それらのＩＤが合致しない場合（ステップ６０８から「いいえ」方向）、処理装置１１４は、ユーザー１１０がグループ４０４に属するかチェックすることができる（ステップ６１０において）。一つの実装において、処理装置が、オブジェクトのｖノード２０４／ファイルシステム・オブジェクトのiノード中の、オブジェクトのグループＩＤをチェックすることができる。ユーザーＩＤはオブジェクトのグループＩＤと比較することができる。もしユーザーが、ファイルシステム・オブジェクトのｖノード中のグループ４０４に属しているなら、信頼されているクライアント上のグループモードビット３０４が参照され得る（ステップ６１６において）。もしユーザー１１０が、信頼されているクライアント上のグループモードビット３０４に基づき十分な許可を有するなら、ユーザー１１０はオブジェクトへのアクセスが許可され、そうでない場合は、ユーザー１１０はアクセスが拒否される。

もしユーザー１１０がグループ４０４に属していないなら、ステップ６１４において、その他モードビット３０６が参照される。もしユーザー１１０がその他モードビット３０６に基づきアクセス許可を有するなら、ユーザー１１０はオブジェクトへのアクセスを許可され、そうでない場合は拒否される。

さらに、ステップ６０２において、もしクライアントが非信頼クライアント１１８であったなら、方法６００はステップ６０６に進む。ステップ６０６において、ユーザー１１０がオブジェクトのオーナー４０２であるかどうかの判断がされる。もしユーザーがオーナー４０２であるなら（ステップ６０６から「はい」方向）、本件方法はステップ６２０に進み、もしそうでないなら、処理装置１１４はステップ６１４においてその他モードビット３０６を参照することができる（ステップ６０６から「いいえ」方向）。

ステップ６２０において、処理装置１１４が、Ｌビット３１０が有効になっているかチェックする。もしＬビット３１０が有効なら（ステップ６２０から「はい」方向）方法６００はステップ６２２に進み、そうでないなら方法６００はステップ６１４に移動し（ステップ６２０から「いいえ」方向）、ユーザー１１０にアクセスが許可される前にその他モードビット３０６がチェックされる。

ステップ６２２において、処理装置１１４は、非信頼クライアント１１８がオブジェクトのｖノード２０４に含まれているかどうかをチェックする。もし非信頼クライアント１１８がオブジェクトのｖノード２０４で記載されていれば、ステップ６１２においてオーナーモードビット３０２を参照し、そうでないなら、アクセスはその他モードビット３０６に基づく。

さらに、方法６００において、もしＴビットが無効の場合（すなわち０）、そうするとアクセスは拡張アクセス許可の最初の９ビットに基づくことになり、拡張アクセス許可は従来のアクセス許可と読み得る。

上で書いた説明は特定の実施態様のみを説明したもので、本発明を限定する意図はなく、本発明の範囲は以下に明示される特許請求の範囲のみにより判断される。本明細書で使用されているように、単数形は、文脈で明示的に反対のことを示している場合を除き、複数形も含むことを意図している。「含む」という言葉を本明細書で使用されたときは、きめられた特徴、整数、ステップ、操作、要素、および／または構成要素の存在を特定するが、一つ以上の特徴、整数、ステップ、操作、要素、構成要素、および／またはそれらのグループの存在を除外していない。

以下の特許請求の範囲中の、すべての手段(means)またはステップ(step)プラスファンクション（function）要素に対応する構造(structure)、材料(material)、動作(acts)および均等物は、特にクレームされた他の特許請求の範囲の構成要素と組み合わせて機能を発揮するための、任意の構造、材料、または動作を含むことを意図している。特許請求された発明の説明は例示および説明を目的として示され、網羅的であることまたは開示された形態の発明に限定されることを意図するものではない。当業者にとって、本発明の範囲または概念から逸脱せずに、多くの修正および変更がありうることが明らかであろう。実施態様は、本発明の原理および実用的な応用例を最もよく説明するために、および、当業者が、意図する特定の用途に適するような種々の修正を伴う種々の実施例に関して本発明を利用することを可能にするために、選ばれ且つ記述されたものである。

Claims (32)

1. 分散ファイルシステムにおけるアクセスを提供するための方法であって、
   アクセスを要求しているユーザーのユーザー識別子（ＩＤ）およびクライアントＩＤを読み出すステップと、
   前記クライアントＩＤが少なくとも信頼されているクライアントまたは非信頼クライアントの内の一つに対応するものであるか判断するステップと、
   ファイルシステム・オブジェクトの拡張アクセス許可を入手することであって、前記拡張アクセス許可は前記ファイルシステム・オブジェクトが信頼されているクライアント上で作成されたかおよび前記ファイルシステム・オブジェクトに非信頼クライアントがアクセスできるか示すステップと、
   前記ユーザーＩＤ、前記クライアントＩＤ、および前記ファイルシステム・オブジェクトの前記拡張アクセス許可に基づき前記ファイルシステム・オブジェクトにアクセスを許可するステップと、
   を含む、方法。
2. 第１のビット（Ｔ）は、前記ファイルシステム・オブジェクトが信頼されているクライアント上で作成されたかを示し、および第２のビット（Ｌ）は、前記ファイルシステム・オブジェクトに非信頼クライアントがアクセスできるか示す、請求項１に記載の方法。
3. 前記ユーザーＩＤ、前記クライアントＩＤ、および前記ファイルシステム・オブジェクトに基づき、ルートユーザー、信頼されているクライアント上のオーナー、非信頼クライアント上のオーナー、信頼されているクライアント上のグループメンバー、非信頼クライアント上のグループメンバー、その他のユーザーを含むリストから、前記アクセスを要求しているユーザーのタイプを判断するステップ、
   をさらに含む、請求項１または２に記載の方法。
4. 前記ファイルシステム・オブジェクトにアクセスを許可するステップは、
   前記アクセスを要求しているユーザーのタイプに対応した前記拡張アクセス許可をチェックするステップ、
   を含む、請求項３に記載の方法。
5. 前記拡張アクセス許可は、
   オーナーモードビット、信頼されているクライアント上のグループモードビット、およびその他モードビット、
   をさらに含む、前記いずれかの請求項に記載の方法。
6. 前記許可するステップは、
   前記アクセスを要求しているユーザーがルートユーザーで、前記クライアントＩＤが信頼されているクライアントに対応するときに、前記アクセスを要求しているユーザーにアクセスを許可するステップ、
   をさらに含む、請求項５に記載の方法。
7. 前記ファイルシステム・オブジェクトにアクセスを許可するステップは、
   前記アクセスを要求しているユーザーが信頼されているクライアント上のオーナーであるとき、前記オーナーモードビットに基づきアクセスを許可するステップ、
   をさらに含む、請求項５または６に記載の方法。
8. 前記ファイルシステム・オブジェクトにアクセスを許可するステップは、
   前記アクセスを要求しているユーザーが非信頼クライアント上のオーナーであり、前記ファイルシステム・オブジェクトが非信頼クライアント上で作成されたとき、前記オーナーモードビットに基づきアクセスを許可するステップ、
   をさらに含む、請求項５、６、または７に記載の方法。
9. 前記ファイルシステム・オブジェクトにアクセスを許可するステップは、
   前記アクセスを要求しているユーザーが非信頼クライアント上のオーナーであり、前記ファイルシステム・オブジェクトが信頼されているクライアント上で作成され、非信頼クライアントは前記ファイルシステム・オブジェクトにアクセスを許可されないとき、前記その他モードビットに基づきアクセスを許可するステップ、
   をさらに含む、請求項５、６、７、または８に記載の方法。
10. 前記ファイルシステム・オブジェクトにアクセスを許可するステップは、
    前記アクセスを要求しているユーザーのタイプが非信頼クライアント上のオーナーであり、非信頼クライアントは前記ファイルシステム・オブジェクトにアクセスを許可され、前記クライアントＩＤが前記ファイルシステム・オブジェクトのiノードの中に存在するとき、前記オーナーモードビットに基づきアクセスを許可するステップ、
    をさらに含む、請求項５から９に記載の方法。
11. 前記ファイルシステム・オブジェクトにアクセスを許可するステップは、
    前記アクセスを要求しているユーザーのタイプが非信頼クライアント上のグループメンバーのときに、前記その他モードビットに基づきアクセスを許可するステップ、
    をさらに含む、請求項５から１０に記載の方法。
12. 前記ファイルシステム・オブジェクトにアクセスを許可するステップは、
    前記アクセスを要求しているユーザーのタイプが信頼されているクライアント上のグループメンバーのときに、前記信頼されているクライアント上のグループモードビットに基づきアクセスを許可するステップ、
    をさらに含む、請求項５から１１に記載の方法。
13. 前記ファイルシステム・オブジェクトにアクセスを許可するステップは、
    前記アクセスを要求しているユーザーがその他ユーザーであるとき、前記その他モードビットに基づきアクセスを許可するステップ、
    をさらに含む、請求項５から１２に記載の方法。
14. 分散ファイルシステムにおけるアクセスを提供するためのシステムであって、
    ファイルシステム・オブジェクトを保存するためのメモリ、
    アクセスを要求しているユーザーＩＤおよびクライアントＩＤを読み出し、
    前記クライアントＩＤが信頼されているクライアントまたは非信頼クライアントに対応するものであるか判断し、
    ファイルシステム・オブジェクトの拡張アクセス許可を入手するためであって、前記拡張アクセス許可は前記ファイルシステム・オブジェクトが信頼されているクライアント上で作成されたかおよび前記ファイルシステム・オブジェクトに非信頼クライアントがアクセスできるか示し、
    ユーザーＩＤ、前記クライアントＩＤ、および前記ファイルシステム・オブジェクトの前記拡張アクセス許可に基づき前記ファイルシステム・オブジェクトにアクセスを許可するための、
    処理装置、
    を含む、システム。
15. 第１のビット（Ｔ）は、前記ファイルシステム・オブジェクトが信頼されているクライアント上で作成されたかを示し、および第２のビット（Ｌ）は、前記ファイルシステム・オブジェクトに非信頼クライアントがアクセスできるか示す、請求項１４に記載のシステム。
16. 信頼されているクライアントおよび非信頼クライアントのリストは前記メモリに保存されている、請求項１４または１５に記載のシステム。
17. 前記信頼されているクライアントのリストは、唯一固有のユーザーＩＤを有するすべてのクライアントを含む、請求項１６に記載のシステム。
18. 信頼されているクライアントか非信頼クライアントかは、トラステッド・コンピューティングに基づき判断されうる、請求項１４に記載のシステム。
19. 権限のある信頼されているクライアントのリストは、前記ファイルシステム・オブジェクトのiノードに保存されている、請求項１４に記載のシステム。
20. 前記ユーザーＩＤが前記ユーザーＩＤおよび前記クライアントＩＤの組み合わせである、請求項１４から１９までに記載のシステム。
21. 前記ユーザーＩＤ、前記クライアントＩＤ、および前記ファイルシステム・オブジェクトに基づき、ルートユーザー、信頼されているクライアント上のオーナー、非信頼クライアント上のオーナー、信頼されているクライアント上のグループメンバー、非信頼クライアント上のグループメンバー、その他のユーザーを含むリストから、前記アクセスを要求しているユーザーのタイプを判断する手段、
    をさらに含む、請求項１４から２０までに記載のシステム。
22. 前記ファイルシステム・オブジェクトにアクセスを許可することは、
    前記アクセスを要求しているユーザーのタイプに対応した前記拡張アクセス許可をチェックすること、
    を含む、請求項２１に記載のシステム。
23. 前記拡張アクセス許可は、
    オーナーモードビット、信頼されているクライアント上のグループモードビット、およびその他モードビット、
    をさらに含む、請求項１４から２２に記載のシステム。
24. 前記許可することは、
    前記アクセスを要求しているユーザーがルートユーザーで、前記クライアントＩＤが信頼されているクライアントに対応するときに、前記アクセスを要求しているユーザーにアクセスを許可すること、
    をさらに含む、請求項２３に記載のシステム。
25. 前記ファイルシステム・オブジェクトにアクセスを許可することは、
    前記アクセスを要求しているユーザーが信頼されているクライアント上のオーナーであるとき、前記オーナーモードビットに基づきアクセスを許可すること、
    をさらに含む、請求項２３または２４に記載のシステム。
26. 前記ファイルシステム・オブジェクトにアクセスを許可することは、
    前記アクセスを要求しているユーザーが非信頼クライアント上のオーナーであり、前記ファイルシステム・オブジェクトが非信頼クライアント上で作成されたとき、前記オーナーモードビットに基づきアクセスを許可すること、
    をさらに含む、請求項２３、２４または２５に記載のシステム。
27. 前記ファイルシステム・オブジェクトにアクセスを許可することは、
    前記アクセスを要求しているユーザーが非信頼クライアント上のオーナーであり、前記ファイルシステム・オブジェクトが信頼されているクライアント上で作成され、非信頼クライアントは前記ファイルシステム・オブジェクトにアクセスを許可されないとき、前記その他モードビットに基づきアクセスを許可すること、
    をさらに含む、請求項２３、２４、２５または２６に記載のシステム。
28. 前記ファイルシステム・オブジェクトにアクセスを許可することは、
    前記アクセスを要求しているユーザーのタイプが非信頼クライアント上のオーナーであり、非信頼クライアントは前記ファイルシステム・オブジェクトにアクセスを許可され、前記クライアントＩＤが前記ファイルシステム・オブジェクトのiノードの中に存在するとき、前記オーナーモードビットに基づきアクセスを許可すること、
    をさらに含む、請求項２３から２７に記載のシステム。
29. 前記ファイルシステム・オブジェクトにアクセスを許可することは、
    前記アクセスを要求しているユーザーのタイプが非信頼クライアント上のグループメンバーのときに、前記その他モードビットに基づきアクセスを許可すること、
    をさらに含む、請求項２３から２８に記載のシステム。
30. 前記ファイルシステム・オブジェクトにアクセスを許可することは、
    前記アクセスを要求しているユーザーのタイプが信頼されているクライアント上のグループメンバーのときに、前記信頼されているクライアント上のグループモードビットに基づきアクセスを許可すること、
    をさらに含む、請求項２３から２９に記載のシステム。
31. 前記ファイルシステム・オブジェクトにアクセスを許可することは、
    前記アクセスを要求しているユーザーがその他ユーザーであるとき、前記その他モードビットに基づきアクセスを許可すること、
    をさらに含む、請求項２３から３０に記載のシステム。
32. プログラムがコンピュータ上で稼働しているとき、請求項１から１３に記載の方法を実行するように適合されたプログラムコード手段を含む、コンピュータプログラム。

Images