JP2018081384A - 情報処理装置および権限管理方法とプログラム - Google Patents

Abstract

【課題】アプリケーション実行環境のファームウェアバージョンアップがあっても、既にインストールされていたアプリケーションは従来と互換性を保って動作することが可能な情報処理装置および権限管理方法とプログラムを提供する。
【解決手段】バージョンアップ前に動作していたアプリケーションに所定パーミッションを付与するようにして、バージョンアップ前から動作していたアプリケーションかどうかを判別できるようにする。また、バージョンアップ後にパーミッションチェックが追加になった非互換API情報を保持し、バージョンアップ前から動作していたアプリケーションから非互換APIの呼び出しか否かを判別できるようにする。バージョンアップ前から動作していたアプリケーションが非互換APIを呼び出した場合に、パーミッションチェック処理を省いて互換を保つ。
【選択図】図８

Description

本発明は、たとえばアプリケーションからの要求により処理を実行する際の実行権限等を制御する情報処理装置および権限管理方法とプログラムに関わる。

近年、スキャナやプリンタを備えた複合機であるMFP(Multi Function Peripheral)に特定のプログラム実行環境、たとえばJava（登録商標、以下省略）の実行環境を搭載し、後からアプリケーションをインストールして機能追加を行うことができるものが知られている。以下、Javaを例として説明する。このような環境で動作するアプリケーションは、セキュリティの観点から必要最低限のパーミッションのみがシステムから付与され動作するようになっている。ここでパーミッションとは処理の実行が許可されていることを示す権限情報である。

またJavaには、APIの呼び出し元のクラスを辿って権限のないクラス（所定のパーミッションが付与されていないクラス）が含まれていないかをチェックする機構が備わっている。この機構を利用して、システムプログラムは呼び出し元のプログラムをチェックし、パーミッションを持たないアプリからの実行を制限するようになっている。例えば、アプリケーションにシステム全体に影響する設定を行うパーミッションを付与してしまうと、アプリケーションが不正な設定を行い、他のアプリケーションやシステムに悪影響を及ぼすことがある。そのため、一般のアプリケーションにはシステム全体に影響する設定を行うためのパーミッションは付与しないようにして、アプリケーションが不正に設定を変更することを防ぐことができる。

また、パーミッションは不正を防止するための用途だけではなくアプリケーションを特定して処理を切りわける用途でも利用されることがある（例えば特許文献１）。特別なパーミッションを付与したアプリケーションを作成することで、パーミッションの有無チェックによりアプリケーションを区別して処理を切り分けることができる。

一方、近年、MFPでは、ファームウェアのバージョンアップにより製品の機能拡張が行われるようになっており、ファームウェアのバージョンアップでJava実行環境が更新されることがある。Java実行環境が更新されるとJavaAPIの仕様が変更され、前述のパーミッションチェック処理が追加されることがある。

特開２００５−２９３０８４号公報

しかしながら、Java標準API中のパーミッションチェックが追加されると、バージョンアップ前は動作していたアプリケーションがファームバージョンアップにより動作しなくなってしまうことがある。Java実行環境の仕様変更であるため新規のアプリケーションについてはそのような仕様変更を受け入れるべきであるが、既に運用されていたアプリケーションが動作しなくなることはエンドユーザに迷惑をかけることになるため避ける必要がある。

本発明は上記従来例に鑑みて成されたもので、アプリケーション実行環境のファームウェアバージョンアップがあっても、既にインストールされていたアプリケーションは従来と互換性を保って動作することが可能な情報処理装置および権限管理方法とプログラムを提供することを目的とする。

上記目的を達成するために本発明は以下の構成を有する。

アプリケーションをインストールし、動作させることが可能な情報処理装置であって、
前記アプリケーションの実行環境が更新された場合に、前記実行環境の更新前からインストールされていたアプリケーションに対して、更新後の前記実行環境で実行するための互換動作許諾を付与する付与手段と、
プログラムを呼び出したアプリケーションが前記プログラムに対する権限を有するか否かの権限チェックを行うチェック手段と、
前記アプリケーションが前記権限を有すると判定された場合に前記プログラムを実行する手段と
を有し、
前記チェック手段は、前記互換動作許諾が付与されたアプリケーションについては、前記権限を有すると判定する。

本発明によれば、既にインストールされていたアプリケーションに対しては従来互換の動作を実現できるようになり、ファームウェアバージョンアップによりそれまで動いていたアプリケーションが動作しなくなることを防ぐことができる。これによりユーザの利便性が向上する。

本特許の実施例におけるシステム構成図 第一の実施例における画像形成装置１００のハードウェア構成図 第一の実施例におけるアプリケーション実行機能のソフトウェア構成図 第一の実施例におけるアプリケーション毎の属性情報の例を示す図 第一の実施例における権限チェックを行わないライブラリ３０２の処理の流れを示したフローチャート 第一の実施例における権限チェックを行うライブラリの処理の流れを示したフローチャート 第一の実施例におけるアプリ実行基盤３０１の処理の流れを示すフローチャート 第一の実施例におけるセキュリティマネージャ３０３の処理の流れを示すフローチャート 第一の実施例におけるスタックトレース情報の一例を示す図 第一の実施例における非互換API情報保持部３０４が保持している情報の例を示す図 第二の実施例におけるライブラリ３０２から権限チェックを依頼された際のセキュリティマネージャ３０３の処理の流れを示すフローチャート 第二の実施例におけるスタックトレース情報の一例を示す図

以下、本発明を実施するための形態について図面を用いて説明する。
［第一の実施例］
＜システム構成＞
図１は本発明の第一の実施例のシステム構成図である。画像形成装置１００は本実施例を実装した情報処理装置の一例となる画像形成装置で、たとえばデジタル複合機（MFP）である。情報処理装置１０１は画像形成装置１００を管理するためのたとえばパーソナルコンピュータである。ネットワーク１２０は画像形成装置１００と情報処理装置１０１とを接続する。情報処理装置１０１は画像形成装置１００をネットワーク１２０経由で利用するために用いられる。アプリケーションＡ１１０は画像形成装置１００上で動作するアプリケーションの一つの例である。アプリケーションＢ１１１は同様に画像形成装置１００上で動作するアプリケーションのもう一つの例である。画像形成装置１００上には、一つあるいは複数のアプリケーションをインストールし、またそれを動作させることが可能であり、ここではアプリケーションを２つ例示している。以後、「アプリケーション１１ｎ」という表現は、アプリケーションＡ１１０、アプリケーションＢ１１１にて代表されるような一つまたは複数のアプリケーションを指す。アプリケーション１１ｎは情報処理装置１０１からネットワーク１２０を経由してインストールすることが可能である。また、情報処理装置１０１は、ネットワーク１２０を経由して画像形成装置１００のファームウェアを更新することもできる。画像形成装置１００の提供するアプリケーション実行環境（たとえばJavaベースの実行環境）は、ファームウェアにより実現されており、ファームウェアを更新することで更新できる。

図２は画像形成装置１００のハードウェア構成図である。コア部２００はたとえばCPUを有しており、たとえばJavaなどで記述されたアプリケーションを、たとえばJava実行環境等のアプリケーション実行環境により実行できる。これによって、アプリケーションの機能を提供できるほか、スキャナ部２０４やプリンタ部２０５、ネッとワークインターフェース部２０３を用いた処理を制御できる。ユーザインタフェース部２０１は、たとえばキーボードやタッチパネル等を含み、ユーザに対して情報を提供するとともに、ユーザによる入力を受け付ける。記憶装置２０２は、たとえば情報処理装置１０１から受信したジョブに関するデータや、プログラムなどのファイルを格納する。ネットワークインタフェース部２０３は、画像形成装置１００をネットワーク１２０に接続するためのネットワークインタフェースである。スキャナ部２０４は、たとえば原稿文書を光学的に走査して画像データを出力する。プリンタ部２０５は、画像データに基づいて、たとえば紙等のシート上に画像を形成する。フィニッシャ部２０６は、プリンタ部２０５とたとえばインラインで接続され、画像形成されたシートに対して、綴じや折りなどの仕上げ処理を施す。記憶装置２０２には、画像形成装置１００のファームウェアやアプリケーション１１ｎのファイルが格納される。コア部２００は、記憶装置２０２に格納されているファームウェアを読み出して実行することで画像形成装置１００の基本機能を提供する。ファームウェアが提供する基本機能としてはコピーや送信を行う機能や、後からインストールされたアプリケーションを実行する機能（以下、アプリケーション実行機能）などがあげられる。アプリケーション実行機能は、記憶装置２０２から各種アプリケーション１１ｎを読み出して、アプリケーション処理を実行する。

＜ソフトウェア構成＞
図３はアプリケーション実行機能のソフトウェア構成図である。アプリ実行基盤３０１は、アプリケーション１１ｎを動作させるためのフレームワークであり、アプリケーションの管理（インストール／アンインストール／開始／停止／アプリケーションの権限の設定など）を行う。この管理を行うためアプリ実行基盤３０１はアプリケーション１１ｎ毎に属性情報（図４で説明する）を保持している。なお本実施形態では、アプリケーションをアプリと略称することがある。

ライブラリ３０２は、アプリケーション１１ｎがその機能を提供するためのＡＰＩ群であり、Java標準APIや、画像形成装置の機能（スキャン／プリント／画像変換など）を利用するためのAPIを含む。ライブラリ３０２の中にはパーミッションが付与されていないコードに対して実行を制限する制御をおこなっているライブラリや要求元の権限にかかわらず処理を実行するライブラリが含まれる。

セキュリティマネージャ３０３は、Javaのコードに処理を実行させてよいかどうかの権限チェックを行うためのモジュールであり、ライブラリ３０２からの要求により権限チェックを行う。セキュリティマネージャ３０３が、画像形成装置１００における権限管理方法の実行の中心となるモジュールである。

非互換API情報保持部３０４は、ファームウェアが更新された際に旧バージョンのAPIから権限チェック処理が追加・変更になっている非互換APIの情報を保持する。アプリ実行基盤３０１、ライブラリ３０２、セキュリティマネージャ３０３、非互換API情報保持部３０４をまとめてアプリ実行環境と呼ぶことにする。セキュリティマネージャ３０３は、呼び出し元のアプリケーションが旧バージョンのアプリ実行環境の上で動作していたアプリケーションなのかどうかを判定し、そうであれば非互換API情報保持部３０４の情報を参照して権限チェック処理の内容を決定する。詳細は図８フローチャートを用いて後述する。

なお、アプリ実行基盤３０１、ライブラリ３０２、セキュリティマネージャ３０３、非互換API情報保持部３０４（すなわちアプリ実行環境）はファームウェアに含まれる。すなわちファームウェアの更新により更新することができる。アプリケーションＡ１１０、アプリケーションＢ１１１は、ファームウェアには含まれず情報処理装置１０１を使って後からインストールされるものである。

＜属性情報＞
図４（ａ）は、アプリ実行基盤３０１によって管理される、アプリケーション毎の属性情報の一例である。ApplicationID（アプリケーションID）４０１は、アプリケーションを識別するためのIDである。path（パス）４０２は、アプリケーションが格納されている記憶装置２０２上の場所を示すパス情報である。Status（ステータス）４０３は、アプリケーションの状態を示す情報であり、Starting、Started、Stopping、Stopped状態がある。それぞれ、起動処理中、起動状態、停止処理中、停止状態を示す。Permission（パーミッション）４０４は、アプリケーションに許可された権限を示す情報である。この例では３種類のシステムプロパティの読み出しと、通信処理の許可が与えられている。なおパーミッションを含む属性情報は、アプリケーションに限らずライブラリなどについて保持されていてもよい。

＜ライブラリによる処理フロー＞
図５は、パーミッションによる権限チェックを行わないライブラリ３０２の処理の流れを示したフローチャートである。アプリケーション１１ｎから呼び出されると、ライブラリ３０２は、ステップ５０１で、要求された処理を実行する。次にステップ５０２に進み、ライブラリ３０２はステップ５０１の実行結果を呼び出し元のアプリケーション１１ｎに返して処理を終了する。

図６は、パーミッションを持たないコードに対して実行を抑制するライブラリの処理の流れを示したフローチャートである。図６はたとえばコア部２００特にそのＣＰＵにより実行される。ライブラリ３０２はアプリケーション１１ｎから呼び出されると、まずステップ６０１で権限チェックをセキュリティマネージャ３０２に依頼する。次にステップ６０２に進み、ライブラリ３０２は、セキュリティマネージャ３０２から受け取った権限チェックの結果を判定する。もし権限チェックでエラーが発生しなかったと判定した場合はステップ６０３に進む。ステップ６０３では、ライブラリ３０２は要求された処理を実行してステップ６０４に進む。ステップ６０４では、ライブラリ３０２はステップ６０４の実行結果をアプリケーション１１ｎに返して処理を終了する。一方、ステップ６０２にて権限チェックでエラーが発生したと判定した場合はステップ６０５に進む。ステップ６０５ではライブラリ３０２はアプリケーション１１ｎにエラーを返し、要求された処理を実行せずに処理を終了する。

図７は、アプリ実行基盤３０１が起動する際の処理の流れを示すフローチャートである。図７はたとえばコア部２００特にそのＣＰＵにより実行される。アプリ実行基盤３０１は、起動するとステップ７０１にて実行環境が前回起動時からバージョンアップしているかを判定する。判定方法の一例としては、前回起動した時、図７の処理の完了後に実行環境のバージョンを不揮発メモリに保持しておき、起動時に動的に取得したバージョンと不揮発メモリに保存されたバージョン情報とを比較することでバージョンアップの検知を行う方法が挙げられる。すなわち、画像形成装置の起動前の実行環境のバージョンを保存し、保存したバージョンと現在のバージョンとを比較して実行環境が更新されていることを判定する。図７には示していないが、図７の処理の後で実行環境のバージョンを取得して不揮発メモリに保持する。なお実行環境のバージョンは、たとえばアプリ実行基盤３０１をインストール或いはアップデートした際に、たとえば記憶装置２０２の所定の場所に記憶されるのでそれを参照することができる。ステップ７０１にて、比較したバージョン情報が異なるものであれば、バージョンアップしていると判定し、その場合はステップ７０２に進む。ステップ７０２では、アプリ実行基盤３０１はインストールされているアプリケーションのリストを取得してステップ７０３に進む。このときインストールされているアプリケーションは、バージョンアップまえの旧バージョンの実行環境で動作していたアプリケーションであると判断できる。ステップ７０３では、アプリ実行基盤３０１はステップ７０２で取得したアプリケーションのPermission属性情報に互換動作を許すためのパーミッション(CompatPermission)を追加してステップ７０４に進む。図４（ｂ）はCompatPermission（以下、互換動作パーミッションあるいは互換動作許諾または互換動作権限）が追加された後のアプリケーション属性の例である。すなわち、図４（ｂ）に示されたＩＤを持つアプリケーションに対して、新バージョンの実行環境でも動作できる権限が付与されている。

ステップ７０４ではアプリ実行基盤３０１はインストールされているアプリケーションの起動処理を行い、処理を終了する。

一方ステップ７０１でバージョンアップしていないと判定した場合は、ステップ７０４に進み、インストールされているアプリケーションの起動処理を行って処理を終了する。

このように実行環境がバージョンアップしない限りはアプリケーションに対して互換動作パーミッションを付与しないようになっている。よって従来から動作していたアプリケーションのみにパーミッションが付与されることになるため、パーミッションチェックにより新規にインストールしたアプリケーションと従来インストールされていたアプリケーションを区別することが可能になる。

図８は、セキュリティマネージャ３０３が、ライブラリ３０２から権限チェックを依頼された際の処理の流れを示すフローチャートである。図８はたとえばコア部２００、特にそのＣＰＵにより実行される。なお以下の説明において、クラスやメソッドという用語を用いるが、これはアプリケーションがJava等のオブジェクト指向言語で記述されていることを想定しているためで、クラスやメソッドはアプリケーションと読み替えてもよい。またAPIがメソッドで提供されるとすれば、APIをメソッドと読み替えることができる。

アプリケーション１１ｎが呼び出したライブラリ３０２からの呼び出しがあると、セキュリティマネージャ３０３は、まずステップＳ８０１で互換動作パーミッションのチェックを行う。このチェックは全ての呼び出し元を遡って各クラスに互換動作パーミッションが付与されているかを判定する。ステップＳ８０１の判定では、全ての呼び出し元について、その属性情報に含まれたパーミッションを参照し、そこに互換動作パーミッションが登録されているか否かが判定される。全ての呼び出し元とは、呼び出しの連鎖を構成する呼び出し元であり、その特定は、たとえばステップＳ８０３で取得するスタックトレース情報を参照して行ってもよい。この判定は、ライブラリ３０２を直接または間接に呼び出したクラス（またはメソッド）が、アプリ実行環境の更新前にインストールされていたかどうかを判定するためのものである。互換動作パーミッションが付与されていないクラス、すなわちアプリ実行環境の更新後にインストールされたクラスが呼び出しスタック上に存在する場合は、チェックの結果はエラーとする。実行環境のバージョンアップ前から既に動作していたアプリケーションについては前述した通り互換動作パーミッションが付与されるため、ステップＳ８０１のチェックではエラーとしない。しかし、実行環境のバージョンアップ後にインストールされたアプリケーション経由で呼び出された場合は、互換動作パーミッションが付与されていないクラスからの呼び出しになるためエラーとする。なお、ライブラリ３０２に含まれるクラスについては全て処理を実行できる権限が与えられているためスタックトレース上に存在してもエラーにはしない。

次にステップＳ８０２に進み、セキュリティマネージャ３０３は、ステップＳ８０１のチェック結果を判定する。エラーとはされなかった（アプリ実行環境の更新前にインストールされており互換動作パーミッションを付与されたクラス）と判定した場合はステップＳ８０３に進む。ステップＳ８０３では、セキュリティマネージャ３０３はスタックトレース情報を取得する。スタックトレース情報には、セキュリティマネージャ３０３の呼び出しにいたるまでの各メソッドの呼び出し順の情報が含まれる。この情報を辿ることにより、どのメソッドから実行されたのかを確認することができる。図９はスタックトレース情報の例である。この例では、com.aaa.SendAppクラスのstartメソッドの中でcom.aaa.NetAccessクラスのinitメソッドを呼び出していることが分かる。また、initメソッドはjavax.net.ssl.HttpsURLConnectionクラスのsetSSLSocketFactoryメソッドが呼びだしており、そこからcom.zzz.SecurityManagerクラスのcheckSetFactoryを実行していることが分かる。

ステップＳ８０３でスタックトレース情報を取得すると、次にステップＳ８０４に進む。ステップＳ８０４では、セキュリティマネージャ３０３は、ステップＳ８０３で取得したスタックトレース情報と非互換API情報保持部３０４に格納されている非互換API情報とを照合して、権限チェック要求の要求元であるライブラリ３０２が非互換APIであるかどうかを判定する。非互換API情報保持部３０４は、Javaの実行環境バージョン変更に伴いパーミッションチェック処理が追加・変更されたAPI（クラス名/メソッド名）すなわち非互換APIの情報を保持している。図１０は、非互換API情報保持部３０４が保持している非互換API情報の一例である。ステップＳ８０４では、権限チェックの要求元すなわちセキュリティマネージャ３０３を呼び出したメソッド（スタックトレース情報に記録されている）が、非互換API情報に含まれていれば、要求元は非互換API（非互換メソッド）であると判定できる。図９の例では、スタックトレース情報の中にHttpsURLConnectionのsetSSLSocketFactoryメソッドを含んでおり、これがcom.zzz.SecurityManager.checkSetFactoryという権限チェックメソッドを呼び出している。そして非互換API情報を照会すると、HttpsURLConnectionのsetSSLSocketFactoryは図１０の非互換API情報に含まれていることがわかる。そのためステップＳ８０４では、、非互換メソッド（非互換API）からの呼び出しであると判断することになる。ステップＳ８０４で非互換メソッドからの権限チェック要求と判定した場合は、何もせずに処理を終了する。すなわち、この場合には権限チェックを通過したことになる。この場合には、たとえば権限チェック要求の要求元であるライブラリ（例えばAPIあるいはメソッド）は、アプリ実行環境のバージョンアップ前から存在し、かつアプリ実行環境の更新によってパーミッションチェックが追加または変更されている。なおかつ、そのライブラリの呼び出し元には、互換動作パーミッションが付与されている。

一方、ステップＳ８０２でエラーが発生したと判定した場合、およびステップＳ８０４にて非互換API以外からの呼び出しすなわち権限チェック要求であると判定した場合はステップＳ８０５に進む。ステップＳ８０５では、セキュリティマネージャ３０３は、ライブラリ３０２から依頼された権限チェック処理を実行する。すなわち、依頼元のライブラリを呼び出したアプリケーションなどのプログラムに、その依頼元のライブラリを利用する権限があるか否かがチェックされる。例えば、HttpsURLConnectionクラスのsetSSLSocketFactoryメソッドからの権限チェック依頼に対しては、スタックトレース情報に含まれたクラスのメソッドに、RuntimePermission("setFactory")の権限があるかどうかをチェックする。

次に、ステップＳ８０６に進み、セキュリティマネージャ３０３は、ステップＳ８０５の処理に置いてエラーが発生したかどうかを判定する。エラーが発生したとは、ステップＳ８０５において権限がないと判定されたことを示す。エラーが発生していないと判定した場合は処理を終了する。一方ステップＳ８０６にて、エラーが発生したと判定した場合は、ステップＳ８０７に進む。ステップＳ８０７では、セキュリティマネージャ３０３は、呼び出し元にエラーを通知（例外をスローする）して処理を終了する。

図８の手順は、図６のステップＳ６０２に相当し、エラーでないならば、ステップＳ６０３において呼び出されたライブラリ３０２は実行される。

以上説明してきたように本実施形態では、従来動作していたアプリケーションに対して特別なパーミッションすなわち互換動作パーミッションを付与し、更新されたアプリ実行環境に新規にインストールされたアプリケーションと区別できるようにしている。また、非互換APIの情報を保持し、非互換API経由で実行されているかどうかを判断することにより、従来動作していたアプリケーションに対して、更新後の実行環境における互換動作を許すことができるようになる。これにより、ファームバージョンアップ等でアプリケーションが動作しなくなることを防ぐことが出来るようになり、ユーザ利便性が向上する。さらに、更新されたアプリ実行環境に新規にインストールされたアプリケーションについては、たとえばライブラリからの権限チェック依頼に応じてその権限がチェックされる。このため、ユーザの利便性に加えて、新規のアプリケーションについては新たな環境に準拠した動作を行わせることができる。

［第二の実施例］
第一の実施例はアプリケーションが直接ライブラリ３０２を呼び出す場合を想定したものであった。そのため、バージョンアップ後に新規にインストールされたアプリケーションがバージョンアップ前からインストールされていたアプリケーションを利用して間接的にライブラリ３０２を利用する場合に互換動作を実現することができなかった。たとえば図８の手順に従うと、上記ケースではステップＳ８０２でエラーと判定されてしまう。ステップＳ８０６でもエラーと判定されてしまうとエラーとなってライブラリ３０２は実行されない。しかしながら、非互換APIを呼び出している、互換動作パーミッションを付与されたアプリケーションが、互換動作パーミッションを付与されていないアプリケーションから呼び出されていることのみを理由としてその実行を許さないのは不合理である。第二の実施例では、更新後のアプリ実行環境に新規にインストールされたアプリケーションが間接的にライブラリを呼び出す場合でも、互換動作を保つ場合の例を説明する。図１〜７および図１０は第一の実施例と共通であるため説明を省略する。

図１１は、ライブラリ３０２から権限チェックを依頼された際のセキュリティマネージャ３０３の処理の流れを示すフローチャートである。図１１は第１実施形態の図８に代えて本実施形態で実行される。ライブラリ３０２からの呼び出しがあると、セキュリティマネージャ３０３は、まずステップＳ１１０１で互換動作パーミッションのチェックを行う。このチェックは全ての呼び出し元をたどり各クラスに互換動作パーミッションが付与されているかを判定する。互換動作パーミッションが付与されていないクラスが呼び出しスタック上に存在する場合は、チェックの結果はエラーとする。実行環境のバージョンアップ前から既に動作していたアプリケーションについては前述した通り互換動作パーミッションが付与されるため、チェックはエラーとせず正常終了とする。しかし、実行環境のバージョンアップ後にインストールされたアプリケーション経由で呼び出された場合は、互換動作パーミッションが付与されていないクラスからの呼び出しになるためエラーとする。次に、ステップＳ１１０２に進み、セキュリティマネージャ３０３は、ステップＳ１１０１のチェック結果を判定する。エラーとされなかった（正常終了した）と判定した場合はステップＳ１１０３に進む。

ステップＳ１１０３では、セキュリティマネージャ３０３はスタックトレース情報を取得する。スタックトレース情報にはセキュリティマネージャ３０２の呼び出しにいたるまでのメソッドの呼び出し順の情報が含まれる。この情報を辿ることにより、どのメソッドから実行されたのかを確認することができる。次にステップＳ１１０４に進み、セキュリティマネージャ３０３はステップＳ１１０３で取得した情報と、非互換API情報保持部３０４に格納されている情報を照合して、非互換APIからの呼び出しすなわち権限チェック要求であるかを判定する。ステップＳ１１０４において非互換APIからの呼び出しすなわち権限チェック要求であると判定した場合は、何もせずに処理を終了し、非互換APIからの呼び出しではないと判定した場合はステップＳ１１０９に進む。ステップＳ１１０２からステップＳ１１０４については図８のステップＳ８０２からステップＳ８０４と同じ処理である。

一方、ステップＳ１１０２でエラーと判定された場合、ステップＳ１１０５に進む。ステップＳ１１０５では、ステップＳ１１０３と同様にセキュリティマネージャ３０３はスタックトレース情報を取得する。図１２は第二の実施例におけるスタックトレース情報の例である。この例では、第一の実施例のスタックトレース情報（図９）と異なり、com.bbb.BoxAppクラスが別のアプリケーションの機能(com.aaa.NetAccessクラス)を呼び出す構成になっている。BoxAppが互換動作パーミッション(CompatPermission)を付与されていないアプリケーションの場合、図１２のスタックトレースではステップＳ１１０２の判定でエラーと判定される。

次にステップＳ１１０６に進み、セキュリティマネージャ３０３は、ステップＳ１１０４と同様にスタックトレース情報および非互換API情報（図１０参照）を参照して、非互換APIから権限チェック要求であるか、すなわち例えば図１２の権限チェックのためのメソッドcom.zzz.SecurityManager.checkFactoryの要求元であるjavax.net.ssl.HttpsURLConnection.setSSLSocketFactoryが図１０の非互換API情報が含まれているかを判定する。含まれていれば、権限チェック要求は非互換APIからの呼び出しであると判定する。その場合はステップＳ１１０７に進み、非互換APIからの権限チェック要求ではないと判定した場合はステップＳ１１０９に進む。ステップＳ１１０７では、セキュリティマネージャ３０３は、たとえばスタックトレース情報に含まれたアプリケーション等のクラスのうち、ステップＳ１１０１のチェックでエラーの原因となったクラスすなわち、互換動作パーミッションが付与されていないクラスをたとえば図４の属性情報を参照して特定する。前述の例の場合はBoxAppが原因であると特定される。

次にステップＳ１１０８に進み、セキュリティマネージャ３０３は、スタックトレース情報を参照して、ステップＳ１１０２のエラー原因となった（互換動作パーミッションが付与されていない）クラスと、権限チェックの依頼元である非互換APIとの間に他のアプリケーションの呼び出しが含まれていないかを判定する。この「他のアプリケーション」は、Ｓ１１０２でのエラーの原因となっていないアプリケーションである。すなわち「他のアプリケーション」は、アプリ実行環境の更新前からインストールされていた、互換動作パーミッションが付与されたアプリケーションである。そのため、ステップＳ１１０８にて、該当する他のアプリケーションの呼び出しが含まれていると判定した場合は、互換動作パーミッションを持ったアプリを介して間接的に非互換APIを呼び出されたことになる。この場合には、チェック処理を省き処理を終了する。一方、ステップＳ１１０８にて、他のアプリケーションの呼び出しが間に含まれないと判定した場合は、互換動作パーミッションが付与されていないアプリケーションが非互換APIを直接的に呼び出していることとなる。そこで、ステップＳ１１０９に進む。

ステップＳ１１０９では、セキュリティマネージャ３０３はライブラリ３０２から依頼された権限チェック処理を実行する。例えば、HttpsURLConnectionクラスのsetSSLSocketFactoryメソッドからの権限チェック依頼に対しては、そのメソッドを呼び出す権限が付与されているか否か、すなわちRuntimePermission("setFactory")の権限があるかどうかをチェックする。

次にステップＳ１１１０に進み、セキュリティマネージャ３０３はステップＳ１１０９の処理においてエラーが発生したかどうか、すなわち権限が付与されているか否かを判定する。エラーが発生していないと判定した場合すなわち権限が付与されていると判定した場合は処理を終了する。一方、ステップＳ１１１０にてエラーが発生したと判定した場合すなわち権限が付与されていないと判定した場合は、ステップＳ１１１１に進む。ステップＳ１１１１では、セキュリティマネージャ３０３は呼び出し元にエラーを通知（例外をスローする）して処理を終了する。

以上説明してきたように第二の実施例では、互換動作パーミッションのチェックでエラーが発生した場合に、互換動作パーミッションを有するメソッドを介した間接的な呼び出しかどうかをスタックトレース情報から判定してさらに処理を切り分ける。これにより、新しくインストールしたアプリケーションが既に稼働していたアプリケーションを利用して間接的にライブラリ３０２利用する場合でも互換動作を実現することができるようになる。

［その他の実施例］
第一の実施例および第二の実施例においては、アプリ実行基盤３０１が起動時にファームウェアのアップデートを検出して各アプリケーションにパーミッションを付与する構成をとっていた。しかしながら、本特許はこれに限られるものではなく、ファームウェアアップデートを行う際にファームウェアアップデートプログラムが直接アプリケーションのパーミッションを変更するようにしてもよい。

また説明を簡単にするため、互換動作すべきかどうかを判定する際に、所定メソッドからの呼び出しかどうかで判定するようにしていた（Ｓ８０４、Ｓ１１０４）。しかしながら、本特許はこれに限られるものではなく、非互換API情報保持部３０４にメソッドと引数の組み合わせ情報を保持するようにし、引数情報も考慮して判定を行うようにしてもよい。

また第１および第２の実施形態では、アプリケーションにより呼び出されるライブラリが、その権限のチェックが実行環境の更新によって変更された非互換の場合に、互換動作パーミッションを有するアプリケーションに権限があるものとみなしている。ここで条件を緩和し、たとえば互換動作パーミッションを有していればそのアプリケーションは権限を有するものと判定してもよい。

また本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１００ 画像形成装置、１０１ 情報処理装置、１２０ ネットワーク、３０１ アプリ実行基盤、３０２ ライブラリ、３０３ セキュリティマネージャ、３０４ 非互換ＡＰＩ情報保持部

Claims (11)

1. アプリケーションをインストールし、動作させることが可能な情報処理装置であって、
   前記アプリケーションの実行環境が更新された場合に、前記実行環境の更新前からインストールされていたアプリケーションに対して、更新後の前記実行環境で実行するための互換動作許諾を付与する付与手段と、
   プログラムを呼び出したアプリケーションが前記プログラムに対する権限を有するか否かの権限チェックを行うチェック手段と、
   前記アプリケーションが前記権限を有すると判定された場合に前記プログラムを実行する手段と
   を有し、
   前記チェック手段は、前記互換動作許諾が付与されたアプリケーションについては、前記権限を有すると判定することを特徴とする情報処理装置。
2. 前記チェック手段は、前記互換動作許諾が付与されたアプリケーションが、前記実行環境の更新により前記権限チェックが変更されたプログラムを呼び出す場合に、前記アプリケーションは前記権限を有すると判定することを特徴とする請求項１に記載の情報処理装置。
3. 前記アプリケーションの実行環境の更新により前記権限チェックが変更されたプログラムを特定するための情報を保存する保存手段をさらに有し、
   前記チェック手段は、前記プログラムが、前記保存手段に保存された情報で特定されるプログラムである場合に、前記プログラムを前記実行環境の更新により前記権限チェックが変更されたプログラムであると特定することを特徴とする請求項２に記載の情報処理装置。
4. 前記チェック手段は、前記アプリケーションの属性情報に含まれた許諾に関する情報を参照して、前記アプリケーションが前記権限を有するか否かを判定することを特徴とする請求項１乃至３のいずれか一項に記載の情報処理装置。
5. 前記チェック手段により前記アプリケーションが前記権限を有しないと判定された場合には、前記権限チェックの要求元に対してエラーを返すことを特徴とする請求項１乃至４のいずれか一項に記載の情報処理装置。
6. 前記チェック手段は、前記互換動作許諾が付与されていないアプリケーションが、前記互換動作許諾が付与されたアプリケーションを介して前記プログラムを呼び出している場合には、前記互換動作許諾が付与されていないアプリケーションについても前記権限を有すると判定することを特徴とする請求項１乃至５のいずれか一項に記載の情報処理装置。
7. 前記プログラムの呼び出しの連鎖を示すスタックトレース情報を参照して、前記プログラムを呼び出したアプリケーションを特定することを特徴とする請求項１乃至６のいずれか一項に記載の情報処理装置。
8. 前記付与手段は、前記情報処理装置の起動前の前記実行環境のバージョンを保存し、該バージョンと現在のバージョンとを比較して前記実行環境が更新されていることを判定することを特徴とする請求項１乃至７のいずれか一項に記載の情報処理装置。
9. 前記情報処理装置は、スキャナ部とをプリンタ部とを備えた画像形成装置として機能することを特徴とする請求項１乃至８のいずれか一項に記載の情報処理装置。
10. 請求項１乃至８のいずれか一項に記載の情報処理装置としてコンピュータを機能させるためのプログラム。
11. アプリケーションをインストールし、動作させることが可能な情報処理装置における権限管理方法であって、
    前記アプリケーションの実行環境が更新された場合に、前記実行環境の更新前からインストールされていたアプリケーションに対して、更新後の前記実行環境で実行するための互換動作許諾を付与し、
    プログラムを呼び出したアプリケーションが前記プログラムに対する権限を有するか否かの権限チェックを行い、
    前記アプリケーションが前記権限を有すると判定された場合に前記プログラムを実行し、
    前記権限チェックにおいては、前記互換動作許諾が付与されたアプリケーションについては、前記権限を有すると判定することを特徴とする権限管理方法。

Images