JP2007513409A

JP2007513409A - コンピューティング装置における資源の割振り

Info

Publication number: JP2007513409A
Application number: JP2006540595A
Authority: JP
Inventors: アンドリューソールケ，; デニスメイ，
Original assignee: Symbian Software Ltd
Current assignee: Symbian Software Ltd
Priority date: 2003-11-21
Filing date: 2004-11-19
Publication date: 2007-05-24
Also published as: EP1687718A2; GB0327261D0; US20070294698A1; GB2408361B; WO2005052787A2; GB2408361A; WO2005052787A3

Abstract

コンピューティング装置の操作において、あるプロセスが別のプロセスに割り振られた資源を利用できるようにするために、前記プロセスに安全なハンドルが割り振られる。前記安全なハンドルは、前記プロセスが前記資源を識別できないこと、及び前記安全なハンドルの割振りによって可能となった前記資源の何らかの利用を前記プロセスが終了して以降は前記資源へのさらなるアクセスが禁止されることを保証する。

Description

本発明は、コンピューティング装置を操作する方法に関し、詳細には、コンピューティング装置上で実行されるプロセスが使用する資源を割り振る方法に関する。

以下で使用するコンピューティング装置という用語は、どんな形態の電気装置をも網羅すると広義に解釈すべきであり、それには、任意の形態のデジタルスチルカメラやデジタルムービーカメラなどのデータ記録装置、ハンドヘルドコンピュータ及びパーソナルコンピュータを含めた任意のタイプ又は形態のコンピュータ、並びに携帯電話や、スマートフォンや、単一のデバイス内に通信、画像の記録及び／又は再生、及びコンピューティング機能を兼ね備えたコミュニケータ（communicators）や、その他の形態の無線及び有線情報デバイスを含めた、任意の形状因子の通信装置が含まれる。

一般に、コンピューティング装置はオペレーティングシステムの制御下で動作するようにプログラムされる。オペレーティングシステムは、コンピューティング装置の中央処理装置にコードの形で送り込まれる一連の命令によってコンピューティング装置を制御する。このような命令は、オペレーティングシステムによってスケジュールされた一連の準自律的な実行基本単位と見なすことができる。このような実行基本単位はそれぞれスレッドとして知られており、コンピューティング装置で実施されるプロセスは必ず１つ又は複数のスレッドを含む。従って、典型的なオペレーティングシステムは、コンピューティング装置のアプリケーションプログラムによって実施される様々なタスクを制御するために、多くの異なるスレッドをスケジュールする。

現在、多くの異なる形態のコンピューティング装置が使用されており、その中にスマートフォンという形態の無線情報装置がある。この装置は、本質的には通信ネットワークに無線接続された単一ユーザ・オペレーティングシステムであるオペレーティングシステムの制御下で動作する。スマートフォンで使用されるオペレーティング・システムの一例は、英国のＳｙｍｂｉａｎＬｉｍｉｔｅｄｏｆＬｏｎｄｏｎから提供されるSymbian OS（登録商標）オペレーティング・システムである。

無線通信装置用のオペレーティングシステムについていえば、コンピューティング装置上で実行されるオペレーティングシステム及びクライアントアプリケーションプログラムは様々なタイプの構成要素に分割することができ、これらの構成要素間には様々な境界がある。これらの構成要素の内のあるものは、一般にカーネルと呼ばれ、それらの構成要素は、コンピューティング装置のハードウェア資源及びソフトウェア資源を管理するために使用される。このような資源には、コンピューティング装置用のハードウェア資源とソフトウェア資源の両方、例えばデバイスメモリ、セマフォ（semaphore）、ミューテクス（mutex）、チャンク（chunk）、メッセージキュー、スレッド、及びデバイスチャネルが含まれ得る。これらの資源は、当業者には周知であり、従って本発明との関連ではこれ以上説明しない。

カーネル構成要素とコンピューティング装置上の他の構成要素との間の境界は、特権境界（privilege boundary）として知られる。カーネルは、クライアントアプリケーションプログラム、例えばスプレッドシート、ワードプロセッサ、或はウェブブラウザプログラムを含めた、コンピューティング装置内に格納されている他の全てのソフトウェア資源が、これらの資源にアクセスできる方法を提供し制御する。カーネル構成要素はまた、オペレーティングシステムの他の部分のためのある種のサービスを提供し、従って、ユーザコマンドと対話するオペレーティングシステムのアウター又はシェルの構成要素とは対照的である。

大部分のコンピューティング装置は、一時に１つの命令しか実行できない。しかし、このようなコンピューティング装置は高速で動作するので、同時に多くのアプリケーションプログラムを走らせ、従って多くのアプリケーションを処理しているように見える。この一見同時に見える動作を達成するために、オペレーティングシステムは、選択された各アプリケーションプログラムに、コンピューティング装置で実行される際に「セッション」を与える。その場合、選択されたプログラムは、セッションが与えられた別のアプリケーションプログラムがコンピューティング装置で実行されている間、待たなければならない。オペレーティングシステムは、これらの各プログラムを、そのタスクを実施するためにコンピューティング装置のある資源が識別され制御される対象となる１つのタスクと見なす。オペレーティングシステムは、１つ又は複数のサーバを使用してこれら複数のアプリケーションにサービスする。この意味でサーバは、コンピューティング装置の１つ又は複数の資源をある程度まで管理する、ユーザインターフェースをもたないプログラムと見なすことができる。サーバは通常、クライアントアプリケーションプログラム（クライアントとしても知られる）が、サーバによって提供されるサービスへのアクセス権を得ることができるように、アプリケーションプログラムインターフェースを提供する。これらのクライアントアプリケーションは、必ずしもアプリケーションプログラムに限られるわけではなく、他のサーバも含み得る。

各サーバは一般に、それ自体のプロセス内で動作し、サーバとその各クライアントとの間の境界はプロセス境界として知られる。アプリケーションプログラムもまた、それぞれのプロセス内で動作し、あるアプリケーションのプロセスと別のアプリケーションのプロセスとの間の境界もプロセス境界として知られる。従ってプロセスを、オペレーティングシステムを保護する基本単位と見なすことができる。というのは、各プロセスがそれ自体のプロセス境界によって定義され、これらのプロセス境界はカーネルの制御の下でなければ越えることができないからである。サーバ並びにアプリケーションプログラムの各プロセスは、オペレーティングシステムによって、コンピューティング装置内にそれ自体のアドレス空間が与えられる。

コンピューティング装置用の大部分のオペレーティングシステムは、マルチタスク処理及びマルチスレッド処理の両方のサポートを提供する。また、システムが各スレッドごとに新しいプロセスを生成するオーバーヘッドを免れるように、プログラムプロセス内でのマルチスレッド処理も可能にする。このようにして、そのプロセスで実行されるアプリケーションプログラムによって使用される仮想アドレスを、コンピューティング装置の読取り専用メモリ（ＲＯＭ）又はランダムアクセスメモリ（ＲＡＭ）内の物理アドレスに変換することができる。この変換は、カーネルの一部を形成するメモリ管理ユニットにより、例えば、読取り専用メモリは共用されるが、あるプロセスで使用される書込み可能なメモリは、通常別のプロセスからアクセス可能でないように管理することができる。

しかし、コンピューティング装置が効率よく動作するためには、カーネルの制御下で資源を共用することが大いに望ましい。これを達成することのできる１つの方法は、ハンドルを使用することである。ハンドルとは、ある資源に、それが使用目的で作成又は開かれた時に、オペレーティングシステムが割り当てる一意の一時的な識別子と見なすことができる。オペレーティングシステム内で動作するプロセスは、資源を使用する必要があるときには必ずハンドルを使用して資源を参照し、ハンドルは当該の資源が閉じられるか削除されるまで有効となる。ハンドルとオブジェクトの間には多くの関係があり得る。例えば、あるハンドルを特定の一オブジェクトに関連付けることもできるし、或はいくつかのオブジェクトに関連付けることもできる。個々のハンドルは通常、それが１つのアプリケーションにだけ有効であるように定義される。例えば、あるハンドルは単一のスレッドについてだけ有効でもよく、単一のプロセスの中の全てのスレッドについて有効でもよい。また、複数のアプリケーションが同一の資源に対し、それぞれ独自のハンドルをもつことも可能であり、さらには、同一資源の単一のコンテクスト中に複数の一意のハンドルが存在することさえ可能である。これは、既存の命名済み資源に対して新しいハンドルを開くことによって達成するか、又は何らかの方法でハンドルを複製して「新しい」ハンドルを作り出すことによって達成することができる。

２つ以上のプロセスが同じ資源にアクセスできることが、時には必要或は有益であり、従って、それぞれがこの資源に対するそれ自体のハンドルをもつ。このような資源「共用」により、プロセス間の連携が可能になり、或はより効率的な動作方法が得られる。第１のプロセスの識別及び第１のプロセスがもつその資源に対するハンドルが与えられている場合、かかる共用を可能にするためにハンドルを複製する方法の１つは、第２のプロセスが新しいハンドルをカーネルに要求することである。実際には、通常、ハンドルは数値であり、従って悪意あるプログラムが、可能性のあるハンドル値を全て試すことによって、最終的には、別のプロセスによって利用されているあらゆる資源に対する複製ハンドルを獲得できるようになるはずである。従って、資源は今や、共用を意図されていなかったものも含めて、全て、悪意あるプログラムからアクセス可能となる。従って悪意あるプログラムにより、第１のプロセスが正しく動作できなくなる。言い換えると、オペレーティングシステムは、コンピューティング装置上で実行される全てのアプリケーションが動作し続けることを保証するために制御することが必要な資源に対する制御を、実際に失うことがあり得る。

従って本発明の目的は、プロセス間で資源をより安全に共用できるように、コンピューティング装置内でハンドルを提供するための改善された方法を提供することである。

本発明の第１の態様によれば、コンピューティング装置を操作する方法であって、あるプロセスが別のプロセスに割り振られた資源を利用できるようにするために、そのプロセスにハンドルを割り振るステップと、そのプロセスがその資源を識別できないようにそのハンドルを構成するステップと、ハンドルの割振りに起因する、そのプロセスによる資源の利用が終了して以降は、そのプロセスによるその資源への更なるアクセスを禁止するステップとを有する方法が提供される。

本発明の第２の態様によれば、第１の態様の方法に従って動作するように構成されたコンピューティング装置が提供される。

本発明の第３の態様によれば、第１の態様の方法に従ってコンピューティング装置内でハンドルの割振りをもたらすコンピュータプログラムが提供される。

次に、本発明を、さらに単なる例により好ましい実施形態に則して説明する。

第３世代プロトコルを使用する新世代の無線電話が利用可能になりつつある。このプロトコルは、主として音声以外のアプリケーション、例えばフルモーションビデオ、ビデオ会議、フルインターネットアクセス用に意図されたはるかに高いデータレートをサポートする。この電話は現在３Ｇ通信として知られてきており、この電話で用いられる無線通信装置は、スマートフォンとして広く知られてきている。

３Ｇ通信のサービス品質条件により、スマートフォン中でこういった通信を実施するために使用される通信スタックを実施するソフトウェアに対して応答時間要件が課される。しかし一般には、スマートフォンのオペレーティングシステムサーバが、コンピューティング装置上で実行されるクライアントアプリケーションの全てに対して応答時間の保証をすることは不可能である。

例えば、コンピューティング装置によってサービスされるＳＭＳ，ＥＭＳ，ＭＭＳ、電子メール及びＦＡＸなどのメッセージは全て、厳密に先入れ先出し（ＦＩＦＯ）順で処理される。これら様々なタイプのメッセージは、それ自体のアプリケーションプログラムを必要とし、従って各メッセージは、それぞれのサーバに対するクライアントと見なすことができる。しかし、サーバは、通常、接続されるクライアントの数やサービスを待つメッセージの数について制約されていない。コンピューティング装置によってサービスされるクライアントには通常、優先順位が与えられる。例えば、電子メールメッセージは、ＳＭＳメッセージより高い優先順位をもつと見なされることがある。しかし上記の事情ゆえに、１つ又は複数のより低い優先順位のクライアントがコンピューティング装置のサービスを待っているという理由で、その「より高い優先順位」のクライアントが、その要求がコンピューティング装置によって処理されるまで、いつまでも待たなければならないことがある。この状況で、既存のクライアント／サーバコードを用いて、より高い優先順位のクライアントにある程度の応答時間の保証を与える唯一の方法は、そのクライアント用の専用サーバを設けることである。しかし、無線通信装置用の典型的なオペレーティングシステムでは、サーバは全てグローバルにアクセス可能な資源であり、従って、上記で概略を説明したように、サーバに対するハンドルを獲得してそのサーバへの接続を試みるローグアプリケーションによるサービス拒否攻撃に対して脆弱である。

本発明によれば、サーバは、アプリケーションがアクセスできる、コンピューティング装置内の他のどの資源とも同じように、匿名サーバを作ることによって攻撃に対する脆弱性が低減される。それにより、クライアントアプリケーションは、サーバの実際の識別ではなく、安全なサーバハンドルを使用してサーバに接続される。この場合、クライアントアプリケーションとサーバの間の専用接続は、既存のクライアント／サーバ接続を用いてコンピューティング装置内の専用通信チャネルを要求することによってセットアップされる。この要求が発行されると、サーバは、要求されたサーバの無名インスタンス化、つまり安全なハンドルを作成し、クライアントアプリケーション用のセッションをこのインスタンス化されたサーバに接続する。次いで、当技術分野では典型的である、「オープン」ハンドル（‘open’handle）と同じやり方で、その結果得られるセッションをオープン共用メカニズム（open sharing mechanism）を介してクライアントアプリケーションに戻す。このようにサーバの無名インスタンス化を行うことにより、サーバは、資源への専用通信チャネルを要求する、いかなるクライアント要求でも認証できるようになる。従って、この提供された機能の乱用を防ぐことができ、更には、この機能によって与えられる便益をいつでも取り除くことができる。

従って、本発明によれば、Symbian OS（商標）のＡＰＩを例として用いると、ＩＰＣ（inter process communication、プロセス間通信）メッセージを介してファイルサーバセッションをクライアントアプリケーションに安全に戻すために必要なのは、次のコードだけである。

RFs fs;
User::LeavelfError(fs.Connect());
User::LeavelfError(fs.ShareProtected());
User::LeavelfError(message.Complete(fs))
従って、プロセス境界をまたぐ共用を含む、効率よく堅牢な「共用可能」セッションが本発明の方法を用いて達成できることが、このコードシーケンスから見て取ることができる。

ハンドルを使用して、プロセス境界をまたいでセッションを共用する周知の方法を用いる場合、セッションとサブセッションはそれらを作成したプロセスから逃れることは不可能であるし、プロセスはそのセキュリティ識別又は諸機能を変更することができない。従って、サーバは、セッション又はサブセッションのユーザが、セッション又はサブセッションの作成元と同じセキュリティ属性を持つと仮定することができるはずである。

従って、一部のオペレーティングシステムでは、共用可能なセッションをサポートする機能をサーバにデフォルトオプションで与えることは、適切でないと考えられる。この場合に、安全なハンドルが使用可能になる前に、プロセス境界をまたいで転送されるセッションを正しくサポートできることをサーバが必ず明示的に示さなければならないように、オペレーティングシステムを構成することができる。従って、クライアントアプリケーションにこの便宜を与えることのできるサーバは、好ましくは、それ自体を潜在的なローグクライアントから、またクライアントをクライアント相互から適切に守ることができると断定するために、一連のセキュリティチェックを行えるように構成されるべきである。

更に、この安全なハンドル機能を使用すると決めたクライアントアプリケーションも、好ましくは、セキュリティ問題を認識するように構成されるべきである。例えば、２つのプロセス間で共用されるファイルサーバセッションの場合、各プロセスは、同じセッションで他方のプロセスが開いたどのファイルにもアクセスできることになる。従って、かかる共用セッションは、当該セッション中に共用される予定のファイルを開くためにだけ使用されることが好ましい。その他のファイルは、完全に専用の（private）セッションを使用するときにだけ開かれるべきである。或は、同じセッションを使用する場合でも、各プロセスが、他方のプロセスのデータかご（data cage）内の他のどのファイルも見ることができないようなやり方で、ファイルサーバを実装することも可能である。

更に、コンピューティング装置上で電子商取引を行うある種のアプリケーションでは、セキュリティを危うくせずにカスタムフォントを使用することが必要になることがある。このようなタイプのアプリケーションを使用する場合、フォントは通常、フォントビットマップサーバとして知られるサーバ内で提供され、フォントファイルは改ざんから保護するためにそのサーバのデータかご内に保持される。これらのフォントの一部は、セキュリティレベルを高めると考えられるので、「専用の信頼される」フォント（‘private trusted’fonts）として知られる。従って、これら「専用の信頼される」フォントの識別は極めて安全に保たれる必要があり、他のアプリケーションがそれらを絶対に使えないようにするために、通常、当該アプリケーションのデータかご内の一ファイルに維持されることになる。

フォントビットマップサーバは、このデータを収めたファイルを見ることができず、従って商取引が発生すると、サーバにこのフォントファイルを転送する方法が必要になる。従来の処理技術では、サーバが一時的にでさえ、このファイルにアクセスできるようにするためにファイルハンドルが使用されることはない。従って、かかるファイルをアプリケーションからサーバに転送しなければならないとき、そのアプリケーションとサーバの間のプロセス境界をまたいで転送が起こることはない。その代わりに、このファイルを転送する全ての通信が、オペレーティングシステムのカーネルによって経路指定される。しかし、これはＣＰＵの時間、ＲＡＭの使用、及び／又はファイルシステムの使用という点で高くつく。これは、例えばスマートフォンで典型的に見られるような、比較的制約された物理資源をもつコンピューティング装置では深刻な欠点になり得る。しかし、本発明の方法を使用すれば、信頼されるクライアントアプリケーションを、安全なファイルハンドル及びセッションだけをサーバに渡すように構成することができ、そうするとサーバは、ファイルの識別を決定せずに、安全なファイルを、クライアントアプリケーションのデータかご内のそれが置かれている場所から直接読み取ることができる。従って、ファイルの安全な識別は維持されるが、コンピューティング装置の改善された効率よい動作がもたらされる。

スマートフォンを含めた移動通信装置でのメッセージサービスの利用がかなり増加してきていることがよく報告されている。これらの装置用のオペレーティングシステムは通常、メッセージサーバを含み、メッセージデータベースはメッセージサーバのデータかごに維持される。このデータベースはまた、通常、メッセージの一部として通信用の添付物を含む。

添付物を見る際、関連するアプリケーションが実行されて、文書内容にアクセスする必要がある。しかし、このアプリケーションは、この文書を保持するメッセージストア内のファイルを見ることができない。考えられる解決策は全て、特にインストールパッケージなど特に大きなファイルを考えると、かなりの負荷及び難点を有する。そうした解決策には、以下のものが含まれる。

・ファイルを一時的な公開位置（public location）にコピーする：これは時間がかかり、ファイルシステム空間を無駄にし、セキュリティ上問題である。

・ファイルをチャンクで、即ち断片的に、開始されたアプリケーションに転送する。やはり、これも時間及びデバイスメモリの負担となる。ファイル内容のセキュリティはより容易に維持できるが、ファイル転送は実際に実装するのが比較的複雑である。

本発明では、その代わりに、添付文書を識別するのではなく、それへのアクセス権を与える安全なファイルハンドルを、メッセージサーバからアプリケーションに渡すことができる。そうすると、アプリケーションはファイル内容を直接、効率的に、但し余計なセキュリティリスクなしに、抽出することができる。

以下のコードは、ファイルサーバがSymbian OS（商標）オペレーティングシステムを用いて、安全にファイルハンドルを共用できるようにするために必要となるはずの変更を例示したものである。このコードはまた、クライアントアプリケーションにおける使用パターンも例示している。このオペレーティングシステムでは、アプリケーションプログラムからファイルサーバへのセッションは、用語ＲＦｓによって示される。

まず、ファイルサーバは、セッションがグローバルに共用できることをオペレーティングシステムのカーネルに報告できるように構成される。これはファイルサーバのベース・コンストラクタ・コール(base-constructor call) ＣＳｅｒｖｅｒＦｓを置き換える、即ち、
:CServer(aPriority,ESharableSessions)
を
:CServer(aPriority,EGlobalSharableSessions)
で置き換えるだけの単純な問題である。

ファイルサーバは、ファイルサーバセッションが別のプロセスと安全に共用できるような方式で、既にそのセキュリティ検査を実施している。具体的には、ファイルを開くといった作業を実施するとき、要求元の機能及び識別を検査し、セッション中に、キャッシュされた情報に依拠することはない。従って、プロセスＡがファイルサーバセッションに対するハンドルをプロセスＢに渡す場合、プロセスＢは、プロセスＢのデータかご内のファイルを開くことしかできず、プロセスＡはプロセスＢのデータかご内のファイルを開くことしかできない。

しかし、オープンサブセッションオブジェクトは、クライアントアプリケーションがサブセッションへのフルアクセス権を持つことを前提とする作業を実施することができる。具体的には、コードＲＦｉｌｅ：：Ｒｅｎａｍｅ（）は、ファイルを、それが置かれているディレクトリから実際に動かす。従ってこの場合、オリジナルファイルがその動作を要求するクライアントアプリケーションのデータかご内に見つからない場合に、このファイルの移動を妨げるための余分の検査を、このコードの実装に加えるべきである。もう一方のファイルサーバＡＰＩもまた、そのセッションを共用することにより生じるセキュリティ問題が他にないことを保証するために検査されるべきである。

完全を期すため、クライアントアプリケーションがサブセッションハンドルをはっきりと安全に渡すことができるようにするためのサポートもなされるべきである。プロセスＡがＲＦｓ及びＲＦｉｌｅ：：ＳｕｂＳｅｓｓｉｏｎＨａｎｄｌｅ（）をプロセスＢに渡すことができたと仮定する。第１の問題は、戻されたＲＦｓ及びファイルハンドルを用いてＲＦｉｌｅのｉＳｅｓｓｉｏｎ及びｉＳｕｂＳｅｓｓｉｏｎＨａｎｄｌｅを設定する明確な方法がないことである。この問題を是正する１つの単純な方法は、ＲＳｕｂＳｅｓｓｉｏｎＢａｓｅに、次のようなことを行う単純な機能を導入することである。

void RSubSessionBase::Set(const RSessionBase& aSession, Tlnt aHandle)
{iSession=aSession;iSubSessionHandle=aHandle;}
しかし、そうすると、これにより、プロセスＢは、プロセスＡがサブセッションハンドルとしてガーベッジ値（garbage value）を渡し、Ｂがそのハンドルを認証できないという可能性にさらされる。プロセスＢがＲＦｉｌｅオブジェクトを使うとすぐに、それはファイルサーバによってパニス（paniced）される。その代わりに、ファイルサーバは、明示的に関与し、かかる転送に対するハンドル認証を与えることによってこの作業をサポートすべきである。即ち、
Tlnt RFite::Adopt(RFs&aFs, Tlnt aHandle);
この認証は、もう一方の「オープン」ＡＰＩと同じように機能し、「新しい」サブセッションを確立する。ファイルサーバ内で、この関数は次のようなプロセスステップを開始する。

（ａ）ハンドル（aHandle）が、与えられたセッションにおけるファイル制御ブロックに対する真のハンドルであることを検査する（そうでない場合、ＫＥｒｒＢａｄＨａｎｄｌｅを返す）、
（ｂ）同じファイル制御ブロックに対する新しいサブセッションハンドルを作成し、これをクライアントアプリケーションに返す、
（ｃ）古いサブセッションハンドルをセッションから破棄する（それにより実際にその古いハンドルは無効となる）。

ＡＰＩが「複製」ではなく「所有権を移転する」という言葉で表されるのは、対称だからである。即ち、それをクライアントからサーバへの転送とサーバからクライアントへの転送に用いるパターンが本質的に同じなのである。

これを、他のファイルサーバサブセッションオブジェクトに対して行うことが望ましい場合、ＡＰＩはＲｆｉｌｅのそれではなく、一般的なＲｆｓＢａｓｅのそれとすることができるはずである。

以下の例は、どのようにして、本発明による安全なファイルハンドルが、コードを用いて渡され、ＡＰＩを用いてプロセスＢがプロセスＡのデータかご内のファイルにアクセスできるようにすることができるかを示す。プロセスＡ及びＢは、クライアント／サーバ接続を有すると仮定し、Ａがクライアントであるシナリオに加えて、Ａがサーバであるシナリオも示してある。

先に述べたように、共用されるファイルサーバセッションでは、各プロセスが、同じセッションで他方のプロセスによって開かれたどのファイルにもアクセスできることになる。従って、この問題に対する予測される解決策は、共用されている各ファイルごとに専用のセッションを使用することである。以下で説明する例では、プロセスＡはファイル上にオープンハンドルを維持する必要がなく、従ってプロセスＡは、プロセスＢがセッションに対するそれ自体のハンドルを有することを知ると、直ちにそのセッションを閉じることができる。これにより、プロセスＡが他の作業用のセッションを不用意に使用してしまったり、偶然にその専用データをプロセスＢにさらしてしまったりするリスクが最小限になることが保証される。

以下のコード例では、明瞭さを損なわないようサーバインフラストラクチャは省略してあり、値ＥｌｐｃＰａｓｓＦｉｌｅは、クライアント／サーバプロトコルで使用されるＩＰＣ要求の値であり、ＫＴｈｅＦｉｌｅはファイル名である。

従って、Symbian OS（商標）を用いて、安全なハンドルを使用し、プロセスＡをクライアント、次いでサーバとして使用して、プロセスＡとプロセスＢの間でファイルを受け渡すコードの例は、以下のようになり得る。

プロセスＡをクライアントとして
プロセスＡのコード：
RFs fs;
User::LeavelfError(fs.Connect());
CleanupClosePushL(fs);
User::LeavelfError(fs.ShareProtected());
RFile file;
User::LeavelfError(file.Open(fs.KTheFile,EFileWrite));
Tlnt ssh=file.SubSessionHandle();
User::LeavelfError(ipc.SendReceive(ElpcPassFile,TlpcArgs(fs,ssh)));
CleanupStack::PopAndDestroy(&fs);
プロセスＢのコード（ファイルを同期的に使う）
RFs fs;
User::LeavelfError(fs.Open(message,0));
CleanupClosePushL(fs);
RFile file;
User::LeavelfError(file.Adopt(fs,message.lnt1()));
CleanupClosePushL(file);
//now use the file...
CleanupStack::PopAndDestroy(2,&fs);
message.Complete(KErrNone);
プロセスＢのコード（ファイルを非同期的に使う）
RFs fs;
User::LeavelfError(fs.Open(message,0));
CleanupClosePushL(fs);
RFile file;
User::LeavelfError(file.Adopt(fs,message.lnt1()));
CleanupStack::Pop(&fs);
//now stash fs/file somewhere safe,close them when finished
message.Complete(KErrNone);
プロセスＡをサーバとして
プロセスＡのコード：
RFs fs;
User::LeavelfError(fs.Connect());
CleanupClosePushL(fs);
User::LeavelfError(fs.ShareProtected());
RFile file;
User::LeavelfError(file.Open(fs,KTheFile,EFileWrite));
message.WriteL(0,TPckgC＜Tlnt＞(file.SubSessionHandle()));
message.Complete(fs);
CleanupStack::PopAndDestroy(&fs);
プロセスＢのコード
TPckgBuf＜Tlnt＞ ssh;
Tlnt h=ipc.SendReceive(ElpcPassFile,TlpcArgs(&ssh));
RFs fs;
User::LeavelfError(fs.SetRetumedHandle(h));
CleanupClosePushL(fs);
RFile file;
User::LeavelfError(file.Adopt(fs,ssh()));
CleanupClosePushL(file);
//now use the file ...
CleanupStack::PopAndDestroy(2,&fs);
クライアント／サーバ接続が資源を共用できるようにする他の手段を使用することも可能である。本発明の方法はまた、カーネル資源に適用して、それらを親プロセスから子プロセスに安全に受け渡すことができるようにすることもできる。受け渡される資源の数及びタイプは、２つのプロセスによって決まり得るはずであり、従って比較的単純なＡＰＩで間に合う。適切なＡＰＩの例は以下のようになり得る。

RProcess::SetParameter(Tlnt alndex,RHandleBase aHandle);
このＡＰＩは、プロセスが作成された後、但し再開される前に、プロセス上で呼び出されなければならない。これにより、ハンドルによって参照されるオブジェクトが、鍵「ａｌｎｄｅｘ」をもつプロセス環境に付け加えられることになる。

RMutex::Open(Tlnt aArgumentlndex, TOwnerType aType=EOwnerProcess);
「ａｌｎｄｅｘ」という鍵の付いたミューテックス資源に対するハンドルを得るために、子プロセスによって呼び出される。これは異なる各鍵値ごとに一度だけ呼び出すことができる。同様のＡＰＩが、この方法で共用できる全ての資源タイプ用に存在するはずである。

本発明を特定の実施形態に則して説明してきたが、添付の特許請求の範囲によって定義される本発明の範囲を逸脱することなく変更形態が成立し得ることが理解されよう。

Claims

コンピューティング装置を操作する方法であって、
あるプロセスが、別のプロセスに割り振られた資源を利用できるようにするために、前記プロセスにハンドルを割り振るステップと、
前記プロセスが前記資源を識別できないように前記ハンドルを構成するステップと、
前記ハンドルの割振りに起因する前記プロセスによる前記資源の利用が終了した後は、前記プロセスによる前記資源への更なるアクセスを禁止するステップと、
を有することを特徴とする方法。
前記別のプロセスに割り振られた複数の資源が前記プロセスによって利用できるように前記ハンドルが構成されることを特徴とする請求項１に記載の方法。
前記別のプロセス以外の複数のプロセスが、前記別のプロセスに割り振られた前記資源を利用できるように前記ハンドルが構成されることを特徴とする請求項１又は２に記載の方法。
前記資源が、コンピューティング装置のメモリ、セマフォ、ミューテクス、チャンク、メッセージ・キュー、スレッド、ファイル、或はデバイス・チャネルのうちの少なくとも１つを含むように選択されることを特徴とする請求項１乃至３のいずれか１項に記載の方法。
前記資源がファイルを含む場合、前記ファイルが前記別のプロセス用の信頼されるフォント・ファイル又はメッセージ添付ファイルのうちの少なくとも１つを含むことを特徴とする請求項４に記載の方法。
前記資源は、前記別のプロセス内のデータかごに存在していることを特徴とする請求項４又は５に記載の方法。
前記プロセスは、ファイル・サーバを含むように選択されることを特徴とする請求項１乃至６のいずれか１項に記載の方法。
前記ファイル・サーバが、それが前記サーバに対する前記ハンドルの割振りに先立って前記資源の利用をサポートできることを、前記コンピューティング装置用のオペレーティング・システムのカーネルに示すように構成されることを特徴とする請求項７に記載の方法。
前記サーバに対するファイル・ハンドルの割振りと同時に、前記サーバとの通信セッションを終了するように前記別のプロセスが構成されることを特徴とする請求項７又は８に記載の方法。
前記別のプロセスが親プロセスを含み、前記プロセスが子プロセスを含み、前記資源が前記コンピューティング装置用のオペレーティング・システムのカーネル資源を含むことを特徴とする請求項１に記載の方法。
前記ハンドルは、前記資源へのアクセスを必要とするサーバの無名インスタンス化として与えられることを特徴とする請求項１乃至１０のいずれか１項に記載の方法。
請求項１乃至１１のいずれか１項に記載の方法に従って動作するように構成されたコンピューティング装置。
無線通信装置を含む請求項１２に記載のコンピューティング装置。
請求項１乃至１１のいずれか１項に記載の方法に従ってコンピューティング装置を動作させるコンピュータ・ソフトウェア。