Apacheサービスを HTTPDアカウント(Usersグループ)で走らせるようになってから、sqlite3.dllを使う、Rubyで書かれた CGIスクリプトが「logic error or missiing database」を出すようになった。
エラーを直接投げてるのは Rubyのライブラリの sqlite3-rubyだけど、エラーメッセージは SQLiteのライブラリ(sqlite3.dll)に由来している。
エラーを出す原因となった SQLは以下。
SELECT * FROM sqlite_master WHERE type='table' OR type='view' ORDER BY name;
データベース内のテーブルとビューの一覧を取り出すためのありふれた SQL文。
問題をややこしくしたのは
SELECT * FROM sqlite_master WHERE type='table' ORDER BY name;
だとか
SELECT * FROM sqlite_master WHERE type='view';
でも同じエラーが出るのに
SELECT * FROM sqlite_master WHERE type='table';
だとエラーが出なかったこと。
結論から言うと SQL文は悪くない。
Apacheを SYSTEMアカウントで動かすとエラーが出なくなったので、Apache(と Apacheが CGIとして起動する Ruby)が HTTPDアカウント(Usersグループ)で動いてることに原因があると考えた。それなら書き込み権限がないせいでエラーになってるのかもしれない。
データベースファイルやデータベースファイルを入れるディレクトリには当然 HTTPDに対して書き込み権限を付けてある。
SysInternalsの FileMonを使って確認したところ、ruby.exeが C:\WINDOWS\sqlite_XXXXXX(文字化け) を CREATEしようとして Denyされている。
sqlite-3.3.4の os_win.cに
char *sqlite3WinFullPathname(const char *zRelative)
という関数があり、Cygwinや WINCE以外の WINDOWSプラットフォームではそこから
GetFullPathNameW/A
という APIが呼ばれている。おそらくこの APIが "C:\WINDOWS\sqlite_XXXXXXX" というパスの出所だろう。
ここをいじって
"%TEMP%\sqlite_XXXXXXX" => "%USERPROFILE%\Local Settings\Temp\sqlite_XXXXXXX => "C:\Documents and Settings\HTTPD\Local Settings\Temp\sqlite_XXXXXXX"
上のような Tempディレクトリにファイルを作成するようにするのもアリだろうが、そういう変更をすると SQLiteのバージョンアップに追従するのが面倒になるので Rubyスクリプトの方で対処する。
sqlite3-rubyでは
db = SQLite3::Database.new('hoge.db');
db.temp_store = 2; # 2=memory, 1=file
SQLでなら
PRAGMA temp_store = MEMORY;
(参照) Pragma statements supported by SQLite
SQLの方は試してないけど、sqlite3-rubyの方で対処したところエラーが出なくなった。
エラーメッセージが的外れなのでここまで来るのに苦労した。
PRAGMA temp_store_directory;
PRAGMA temp_store_directory = 'directory-name';
Query or change the setting of the "temp_store_directory" - the directory where files used for storing temporary tables and indices are kept. This setting lasts for the duration of the current connection only and resets to its default value for each new connection opened.
When the temp_store_directory setting is changed, all existing temporary tables, indices, triggers, and viewers are immediately deleted. In practice, temp_store_directory should be set immediately after the database is opened.
The value directory-name should be enclosed in single quotes. To revert the directory to the default, set the directory-name to an empty string, e.g., PRAGMA temp_store_directory = ''. An error is raised if directory-name is not found or is not writable.
The default directory for temporary files depends on the OS. For Unix/Linux/OSX, the default is the is the first writable directory found in the list of: /var/tmp, /usr/tmp, /tmp, and current-directory. For Windows NT, the default directory is determined by Windows, generally C:\Documents and Settings\user-name\Local Settings\Temp\. Temporary files created by SQLite are unlinked immediately after opening, so that the operating system can automatically delete the files when the SQLite process exits. Thus, temporary files are not normally visible through ls or dir commands.
%TEMP%フォルダでなく %WINDIR%にテンポラリファイルを作ろうとするのは Windowsのせい？俺のせいでした。
httpd.confに次の行を加えるべし。
PassEnv TEMP
確かに、確かに萌えが存在している。ギャップだとか弱点に萌えが宿るのは真実。何かのインタビューで桜庭さんが仰っていた通りです。
http://www5a.biglobe.ne.jp/~dai_/diary/diary0602.htm#05 (DAIさん帝国)
標準シールドの詳細な設定に「新規作成/修正されたファイルを検査」という項目がある。
これにチェックを入れて、さらにその下のラジオボタンで すべてのファイルを対象にしたとしても、ウィルスファイルが作成されるのを検知できないことがある。
こういう状況で C:\Data Files\HOGE.ZIP を解凍(エクスプローラの「全て展開」を使用)して、C:\Data Files\HOGE\VIRUS.FILE というウィルスファイルが作成されても Avastは検知しない。
比較のために C:\Documents and Settings\UserName\デスクトップ\HOGE.ZIP を解凍してみたが、これは検知した。
さらに試すと、Data Files\HOGE.ZIP の展開先をデスクトップにした場合、Avastはウィルスを検知するが、逆に デスクトップ\HOGE.ZIP を Data Filesに展開した場合はウィルスを検知できない。
総合すると、別の HDDがマウントされているフォルダの下にウィルスファイルが作成されても Avastは検知できない。
違った。この HDDに Zドライブを割り当てて C:\...\デスクトップ\HOGE.ZIPを Z:\HOGE\VIRUS.FILE に解凍してみても検知しなかった。Cドライブから、同じ HDD上の違うパーティションである Dドライブに解凍したら検知した。
結局のところ、ウィルスファイルの解凍先がパーティションをまたいでいたとしても同じ HDD内なら検知するが、解凍先が違う HDDのときは検知しない。それとは別に、解凍先が、別の HDDが割り当てられたフォルダ*の下であった場合は、ウィルスの入った ZIPファイルとその解凍先が同じ HDDであろうがなかろうが検知しない。
* `dir`によると<DIR>ではなく<JUNCTION>
ファイルの変更履歴が保存できるのが嬉しくて、前から入れたかった Subversion。リポジトリのブラウズに最初は ViewCVSを使うつもりで Pythonまでインストールしたのにローカルでの CGIの実行環境が整わずに挫折していた。
今度は WebDAVを使ってエクスプローラの Webフォルダ(マイネットワーク→ネットワークプレイスの追加)と ウェブブラウザの Firefoxでブラウズすることにした。
ダウンロードしてきた Subversionのバイナリパッケージに含まれてた mod_dav_svn.soが Apache2.0.54向けだってので、Apache2.2.0にはロードできなかったので 仕方なく、最新(の安定版)じゃないけど仕方なく Apache2.0.55をインストール。
以前 Apacheをコンパイルしようとして apr, apr-iconv, apr-utilといった Apacheから利用されるライブラリのコンパイルの段階で失敗してたので今回は素直にインストーラを利用。Windowsの何が困るって ./configure できないのがそうとう痛い。configure の一行目に #!/bin/sh とか書いてあってもシェルスクリプトが実行できないし、実行してくれるシェルもないし。Microsoftは wshに続いて、Vistaの後には mshを出してくるみたいだけど、シェルスクリプトの実行できないシェルは要らないですよ。
Apacheの設定は簡単。モジュール毎のディレクトリリファレンスと目的別に書かれた記事が使いやすいし、セキュリティ上注意を要する設定には囲みで目立つように注意が書かれてるし、ドキュメントの大部分が日本語に翻訳されてるし。
http://localhost, http://localhost/~user/, http://localhost/svn/の表示に成功。詰まった箇所は二つ。
せっかく Apacheをサービスとして常時動かすのだからと、無料の DDNSサービスを利用して外部に公開することにした。この PCが起動していれが https://sn25p.dip.jp でアクセスできるはず。
mod_sslの設定は右を参照。The Apache + SSL on Win32 HOWTO
公開の目的は不特定多数の人間にアクセス/攻撃してもらうためでなく、ネット越しに自分の PCにアクセスできたら録画予約も HDDに保存したファイルの編集も 貯まってる aviの視聴も思いのままだな、ってことなので
XP Home Editionでそういうことをやろうと思ったら (ようこそ画面にも表示される)「ユーザー」を新しく作成するしか方法がなさげ。ASPNETという見えないユーザーが既に存在しているのでできるないことはないはずなんだが。
Home Editionは関係なかった。Apache用のアカウントを作成してから、HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList をいじれば非表示にできる。
とりあえず HTTPDというユーザーを作って Apacheのサービスをこのアカウントで実行しようとしたがログオンエラーになる。どうも「サービスとしてログオン」する権限を与えないといけないらしい。XP Homeには「ローカルセキュリティポリシー」なんて GUIの管理ツールがないので Windows 2000 Resource Kitをダウンロードしてきてコマンドラインで
ntrights -u HTTPD +r SeServiceLogonRight
とする。パスワードが空の時もログオンに失敗するのでパスワードも設定した。OK。
(以下、ぼやき) Home Editionだからって \WINDOWS\System32\lusrmgr.msc(ローカルユーザーとグループ) が実行できないのは非常に困る。さらにいえば今回の様な目的では、(XP Proの機能である)リモートデスクトップさえ使えれば Apacheを使う必要もなく、Apacheを使った以上のことができるのだけど。MSは Homeと Professional Editionをうまく分けてると思うよ。買う前はそんなに機能が削減されてるとは思わなかったけど Home Editionを実際使ってみると、おさえるべき所はきっちり Professional専用の機能としておさえられている。
もう少し下位のレベルでと思って IPSecについても検索したけど Home Editionは「ローカルセキュリティポリシー」が管理ツールとコンパネに含まれてないので設定できない。こんな所にも Homeの制限が。企業と違って個人ユーザーは通信内容が漏れても構わない(というか致命的ではない)よね、っていうのが Home Editionの「Home」の意味なんだと理解。