Roaming, Local, LocalLow

Roaming, Local, LocalLow

Vista以降、Windowsはアプリケーションが設定等を保存する場所として、%USERPROFILE%\AppData以下にRoaming, Local, LocalLowという3つのフォルダを用意している。%APPDATA%はRoamingに割り当てられているのだが、では他の2つとの使い分けはどうなるのか。

これを満足なレベルで解説してるところがあまり見つからず、自分で簡単に調べてみたのでメモ。

 Roamingの正体

恐らく第一の答えはkb955555（機械翻訳版）になるだろう。（後で気づいたがTechNetの方に同等内容の公式な日本語訳があった）

機械翻訳版はどうも気持ち悪いので頑張って原文を訳してみる。

Windows Vista uses the Local and LocalLow folders for application data that does not roam with the user.

Usually, this data is specific to the computer or is too large to roam.

The AppData\Local folder in Windows Vista is the same as the

Documents and Settings\UserName\Local Settings\Application Data folder in Windows XP.

Windows uses the Roaming folder for application-specific data that is independent of the computer

and that should roam with the user profile, such as a custom dictionary.

The AppData\Roaming folder in Windows Vista is the same as the Documents and Settings\UserName\Application Data folder in Windows XP.

Windows Vistaはユーザと共に移動しないアプリケーションデータにLocalとLocalLowフォルダを使用します。

通常、このデータはコンピュータに固有であるか、移動するには大きすぎるものです。

Windows VistaのAppData\LocalフォルダはWindows XPのDocuments and Settings\UserName\Local Settings\Application Dataフォルダと同じです。

WindowsはRoamingフォルダを、ユーザ辞書のような、ユーザプロファイルと共に移動すべきで、コンピュータから独立しているアプリケーション固有のデータに使用します。

Windows VistaのAppData\RoamingフォルダはWindows XPのDocuments and Settings\UserName\Application Dataと同じです。

つまり、ドメイン環境で「どのユーザがどのコンピュータを使うか分からない」ような状況でも、ユーザのプロファイルの一部としてどのコンピュータからログインしても使えるべきデータは、サイズが大きすぎない限りRoamingに格納される。

一方、ハードウェアに関連があったり、ログイン・ログオフで毎回やりとりするには大きすぎるデータはLocalまたはLocalLowフォルダに格納される。

はて、これではLocalとLocalLowの使い分けが分からない。

 LocalLowとは

その先の答えは、MSDNのWindows Vista Integrity Mechanism Technical Referenceにあるようだ。この文書は英文のみ、かつかなり長く、今回の素朴な疑問に答えるためだけに読むには骨が折れる。比較的楽に読み解けそうなのはDesigning Applications to Run at a Low Integrity Levelだが、とにかく3行にまとめると以下の通り。

• integrity level（信頼レベル）というセキュリティ強化の仕組みができた。
• low integrityなプロセスはLocalLowにしか書き込みできない。
• Internet Explorerがlow integrityの代表。

というわけで、LocalとLocalLowの使い分けは書き込むプロセスの信頼性にある。Windowsのセキュリティ機能としては既にユーザアカウントがあるわけだが、同じユーザでも実行するプロセスごとに権限を分けたい、というあたりに目的があるらしい。全文を読んでないのでその価値は判断できないが、「また余計なものを…」という気がしないでもない。

ちなみにLocalLowと同様のものはレジストリにもあり、HKCU\Software\AppDataLowになる。

開発者視点の話

本題から外れるが、integrity levelの開発者視点での話を。といっても実装方法とかの技術的な話ではないけれど。

integrity levelの仕組みは要はsandboxの発想で、個別の脆弱性への対応とは別に、プロセス自体を「暴れてもシステムに影響しない砂場」に閉じこめる方法になる。

でも、開発者の大部分は、正直こんな面倒な仕組みに乗りたくはないだろう。それならばサーバではもうメジャーになった「丸ごと仮想化」の方が楽だし、根本的だ。

ではなぜ、マイクロソフトはこんな中途半端な方法を採ったのか。…まぁ言わずもがな、パフォーマンスと独占市場を崩せないからだろう。丸ごと仮想化してしまった場合、只でさえ遅いと言われてるInternet Explorerの性能はガタ落ちだろうし、OSレベルに持ち込んでるDirectXの力を利用することができなくなる。ファイルのダウンロードや印刷処理なども切り離されるので、マイクロソフトの言うユーザ体験は酷いものになってしまうだろう。

技術屋としては「じゃあUnixみたいに全部C/S処理にすればいいじゃん」と思うのだが、そうするとプロトコルを解析されたら（もしくはEUに公開を求められたら？）、マイクロソフトの望まない、WindowsとInternet Explorerの柔軟な運用を許してしまう。例えばLinux等の上でInternet Explorerが動作したり、逆にInternet Explorerが実現する機能を他のブラウザが簡単に利用できたり。そしてC/Sはネットワークベースの技術だから、またもや脆弱性の問題が出てくる。マイクロソフトとしては、何とかWindowsの内部で済ませたいのだろう。

実は、このintegrity levelの仕組みだって、C/Sの仕組みと変わらない。ファイルのダウンロードでLocalLow以外にファイルが保存できるのは、プロセス間通信でmedium integrityのプロセス（"ブローカー"プロセス）にファイル保存を要求しているからだ。

An application that is running at low integrity may have one part of the application in a low-integrity process, for example to handle untrusted data from the Internet.

Another part of the application can be implemented in a medium-integrity “broker” process to handle a small set of user-initiated actions. Communication between the low-integrity and medium-integrity processes in the application can be handled using various IPC mechanisms.

A better design is for a low-integrity process to call an interface that requests the medium-integrity application to present a common file dialog to the user, which the low-integrity process cannot drive using window messages.

This way, you let the user browse and select what file to open or create, and the medium-integrity process does all the file operations.

This type of Save As scenario is an example of how Protected Mode Internet Explorer uses its own broker process to handle saving a Web page somewhere in the user’s profile.

（もう面倒なので頑張って読んでください）

どうせIPCを使うのであればソケットでC/Sでも良かったはずだし、その方が完全な仮想化をも視野に入れることができるのに、そうはしない。 IPCとソケットを抽象化して透過的なI/Fにする事だって、integrity levelなんて新たな仕組みをOSレベルで導入する事に比べれば遙かに楽なはずなのに。

まぁ、営利企業なのだし自己の利益を保護する方策は当然なのだけれど。技術的に良いと思われる方策よりも、政治的な思惑みたいなところが重視されて、Windowsが使いにくいものにならなければいいなぁ、と思う次第。