Vistaの地平 2.UACと従来のアプリケーションとの互換性畑中 哲2007/04/05 |
|
|
このようなUACによって、「普段は小さな権限のアプリケーションを実行し、大きな権限のアプリケーションは必要なときにだけ実行する」という使い方がやっと実用的になろうとしている。技術的にもなかなかうまい方法なのではないだろうか。
だが最大の問題は、従来のアプリケーションとの互換性だろう。何しろ、これまでのアプリケーションはログオン中のユーザーにすべての権限があることを前提として開発されることが多かったのに、Windows Vistaでは、その前提がほぼ強制的に崩れてしまうからだ。
互換性を維持するための仕組み
そこでWindows Vistaには、UACが有効でも従来のアプリケーションが問題なく動けるように、さまざまな仕組みが用意されている。
インストーラの検出
インストーラは、システム全体に影響する操作をすることが多い。例えば%ProgramFiles%フォルダにファイルをコピーしたり、HKEY_LOCAL_MACHINEレジストリに書き込んだりする。ということは、UACに対応していないインストーラでは、たとえ管理者ユーザーとしてログオンしていてもインストールに失敗することになってしまう。これはセキュリティ上では期待どおりの動作なのだが、このままでは従来のアプリケーションの多くがWindows Vistaにインストールすらできないことになってしまう。
インストーラを自動検出
そこでWindows Vistaでは、インストーラらしき実行ファイル(例えば名前にsetupといった語を含む実行ファイル)を自動的に検出し、特別な対応を行っている。そのような実行ファイルは、実際にはUACに対応していなくても、実行ファイル本来のアイコンに「盾」マークが自動的に付加されて表示される。
インストーラとして検出されたプログラムの例 | |||
これは実際にはWindows Server OS用のあるアプリケーションのセットアップ・プログラム(ファイル名はsetup.exe)。Windows Vista(のUAC)に対応しているわけではないが、「盾」マークが表示されている。
|
ただし、インストーラが一時的にファイルを解凍した後、その中に含まれている別のインストーラがさらに起動する場合などは、この「盾」マークが付いていなくても、UACのダイアログが出る場合もある。
インストーラとして検出されたファイルの実行
インストーラとして検出されると、その実行ファイルは、あたかもUACに対応していて、起動時から昇格(UACによる許可操作)が必要なアプリケーションであるかのように扱われる。そのため、実行ファイルを起動しようとすると、昇格の許可を求めるダイアログ・ボックスが表示される。ユーザーから見ると、アイコンに「盾」マークが付いているのだから、ダイアログ・ボックスで許可を求められるのは自然なことだ。ダイアログ・ボックスで許可すると、実行ファイルは昇格して起動する。許可しないと、実行ファイルは起動しない。
互換性を維持するためとはいえ、本当は昇格が不要なアプリケーションが誤ってインストーラとして検出されてしまうこともあるため、やや疑問も残る仕組みである。
なお、昇格が必要なインストーラなのに自動的に検出されない場合は、次ページの「アプリケーションを最初から昇格して起動するには」の手順によって、手動で昇格させて起動すればよい。
ファイルとレジストリの仮想化
本来はユーザーごとの場所に保存するべきファイル/レジストリをグローバルな場所に保存してしまうアプリケーションは、非常に多い。いわゆる「行儀の悪い」アプリケーションである。
従来のWindowsでは、管理者ユーザーとしてログオンしていれば、そのようなアプリケーションでも一応動作していた。だがUACが有効なWindows Vistaでは、たとえ管理者ユーザーでログオンしていても、そのようなアプリケーションはファイル/レジストリの保存に失敗することになる。これはセキュリティ上は期待どおりの動作なのだが、互換性は大きく損なわれる。
そこでWindows Vistaでは、グローバルな場所の一部が仮想化されている。「仮想化」ではなく「リダイレクト」と呼ばれることもあり、言葉としてはそちらの方が分かりやすいかもしれない。人によっては、プログラミングなどでよく使われる用語である「Copy on Write(*)」という表現がいちばん分かりやすいだろうか。
* 「Copy on Write(書き込み時コピー)」はメモリやディスクの管理などで使われる技法の1つ。あるデータ領域を複数のプログラムから同時に利用する場合、読み出しは元のデータ領域から行うが、書き込もうとすると(更新しようとすると)、まずそのデータ領域のコピーを作成し、以後そのプログラムは、コピーされた領域へアクセス(読み書き)するという技法。書き込もうとした時点でコピーが作成されるのでCopy on Writeと呼ばれる。ほかのプログラムには影響を与えることなく、プログラムごとに固有のデータ領域を確保し、管理することができる。参照よりも書き込みが少ない場合には、効率のよい管理方法である。Window OSではDLLの共有やボリューム・シャドウ・コピーの管理などで利用されている。 |
Windows VistaのUACでは、以下で述べるような領域が仮想化(Copy on Write)の対象となっており、これらの領域を読み出す場合にはそのままアクセスを許可するが、書き込み(変更)を行おうとすると、まず別の場所にコピーを作成してから、そのコピーに対して変更を行う。これにより、ほかのプログラムからは元のデータがそのまま参照できるが(つまり何の変更もないように見えるが)、書き込もうとしたプログラムからは正しく書き込みできたように見えるし、以後は書き込んだ内容が読み出せる。
仮想化される場所
Windows Vistaで仮想化されるのは、以下のグローバルなフォルダとレジストリ・キーである。
- %ProgramData%フォルダ
- %ProgramFiles%フォルダ
- %SystemRoot%フォルダ
- HKEY_LOCAL_MACHINE\Softwareキー
これらに該当する場所でも、.EXE、.DLL、.SYSなどのファイルや、レジストリのSoftware\Classes、Software\Microsoft\Windows、Software\Microsoft\Windows NTキーは仮想化されない。仮想化されないキーは、reg flagsコマンドでREG_KEY_DONT_VIRTUALIZEフラグがセットされているかどうかをクエリすれば確認できる。
C:\>reg flags HKLM\Software\Microsoft query |
仮想化の効果
UACが有効なとき、UACに対応していないアプリケーションがこれらのグローバルな場所に書き込もうとすると、本来は失敗するはずである。だが仮想化の機能によって、書き込みは成功する。書き込んだファイル/レジストリの実体は、グローバルな場所ではなくユーザーごとの場所に保存される。例えばC:\Windowsフォルダにtest.iniというファイルを書き込もうとすると、C:\Windows\test.iniではなく、%LocalAppData%\VirtualStore\Windows\test.iniとして書き込まれる。以後ユーザーがC:\Windows\test.iniというファイルを読み書きしようとすると、%LocalAppData%\VirtualStore\Windowsフォルダにあるtest.iniファイルへアクセスが振り向けられる(C:\Windows内にあるtest.ini以外のファイルの読み出しは、元のC:\Windowsから行われる)。
仮想化されるグローバルな場所 | 実体(ユーザーごとの場所) |
%ProgramData%フォルダ | %LocalAppData%\VirtualStore\ProgramData |
%ProgramFiles%フォルダ | %LocalAppData%\VirtualStore\Program Files |
%SystemRoot%フォルダ | %LocalAppData%\VirtualStore\Windows |
HKEY_LOCAL_MACHINE\Softwareキー | HKEY_USERS\(SID)_Classesの\VirtualStore\MACHINE\SOFTWARE (=HKEY_CURRENT_USER\Softwareの \Classes\VirtualStore\MACHINE\SOFTWARE) (=HKEY_CLASSES_ROOTの \VirtualStore\MACHINE\SOFTWARE) |
仮想化されるオブジェクトとその実体 |
UACに対応していないアプリケーションが仮想化されたグローバルな場所からファイル/レジストリを読み取ろうとすると、まずユーザーごとの場所から読み取られる。ユーザーごとの場所に存在しなければ、グローバルな場所から読み取られる。グローバルな場所にも存在しなければ、読み取りは失敗する。
仮想化の動作は、イベント・ログの[アプリケーションとサービス ログ]−[Microsoft]−[Windows]−[UAC-FileVirtualization]に記録される。
似たような仕組みは従来のWindowsにもいくつか存在するが、「ファイルとレジストリの仮想化」はより本格的なものである。とはいっても互換性を維持するためだけに存在する仕組みであり、マイクロソフトはアプリケーションがこの仕組みに頼らないよう呼び掛けている。64bitアプリケーションやUACに対応しているアプリケーションに対しては、仮想化は効かない。仮想化されたファイルやレジストリは、UACに対応していないアプリケーションからは見えるが、UACに対応しているアプリケーションからは見えないのである。
実体の確認
仮想化によって互換性が維持される半面、同じコンピュータ上で同じ絶対パスでファイルにアクセスしても、ユーザーやアプリケーションによって実体が異なってくるので、混乱しかねない。実体を確認したくなることも多いだろう。だがVistaのエクスプローラはUACに対応しているため、仮想化されたファイルやレジストリはそのままでは見えない。
仮想化されているフォルダでは、[互換性ファイル]というボタンが表示される。同じフォルダでも、仮想化されていなければこのボタンは表示されない。
仮想化されているフォルダ | ||||||
ここでは、UACに対応していないアプリケーションで%SystemRoot%にTEST.INIというファイルを作成した。その結果、現在のユーザーにとってこの%SystemRoot%フォルダは仮想化されているので、[互換性ファイル]ボタンが表示されている。
|
[互換性ファイル]ボタンをクリックすると、実体フォルダが開く。
実体ファイルの確認 | |||||||||
現在のユーザーにとっては%SystemRoot%\TEST.INIファイルが仮想化されていて、実体は%LocalAppData%\VirtualStore\Windowsにあることが分かる。
|
この実体ファイルの場所(%LocalAppData%\VirtualStore)を調べると、逆に何が仮想化されているかを簡単に知ることができる。
起動時に昇格が必要なスタートアップ・プログラムをブロック
アプリケーションによっては、起動時に昇格が必要なものもある。そのようなアプリケーションをスタートアップに登録すると、ログオンするたびに許可を求めるダイアログが表示されることになり、うっとうしくなる。そのため、起動時に昇格が必要なプログラムは、スタートアップに登録してもブロックされて、起動しないようになっている。
ブロックされたスタートアップ・プログラム | |||
起動時に昇格が必要なプログラムは、スタートアップに登録してもブロックされて、起動しない。
|
ブロックされたスタートアップ・プログラムは、タスク・トレイのアイコンで通知される。アイコンをクリックすると、ブロックされたスタートアップ・プログラムをあらためて起動することができる。
INDEX | ||
Vistaの地平 | ||
第8回 管理者権限での実行を制限するユーザー・アカウント制御UAC(後編) | ||
1.UACの技術 | ||
2.UACと従来のアプリケーションとの互換性 | ||
3.アプリケーションの昇格とUACの設定 | ||
「 Vistaの地平 」 |
- Azure Web Appsの中を「コンソール」や「シェル」でのぞいてみる (2017/7/27)
AzureのWeb Appsはどのような仕組みで動いているのか、オンプレミスのWindows OSと何が違うのか、などをちょっと探訪してみよう - Azure Storage ExplorerでStorageを手軽に操作する (2017/7/24)
エクスプローラのような感覚でAzure Storageにアクセスできる無償ツール「Azure Storage Explorer」。いざというときに使えるよう、事前にセットアップしておこう - Win 10でキーボード配列が誤認識された場合の対処 (2017/7/21)
キーボード配列が異なる言語に誤認識された場合の対処方法を紹介。英語キーボードが日本語配列として認識された場合などは、正しいキー配列に設定し直そう - Azure Web AppsでWordPressをインストールしてみる (2017/7/20)
これまでのIaaSに続き、Azureの大きな特徴といえるPaaSサービス、Azure App Serviceを試してみた! まずはWordPressをインストールしてみる
|
|