実際には2011年11月27日にやったこと、とその続き。
Captcha技術の含まれるWordPress pluginを導入してみたらXREAの仕様絡みでエラー吐いてちょっと苦労したよという話。
ド素人が理屈分からず試してるだけなので、似たような状況でも真似しない方が良いような気がします。

plugin何かいれよーと思って探したところ、Fast Secure Contact Formというメールフォームのpluginが目についた。
細かく設定できるメールフォームが簡単に設置できるらしい。インストール。
これがCaptchaを使っているというので、そう言えば前々からコメントスパム除けにCaptcha導入したかったんだ、と思い出しSI Captchaというpluginも導入。

Fast Secure Contact Form設定画面でphpがセーフモードで動作しているのでメール送信とファイルのアップロードが上手くいかないかもとの警告。またCaptchaの生成もphpが云々。こちらはphpを使わないにチェックを入れた。
設定後使ってみると、セーフモードの警告にも関わらずちゃんと動作した。
よきかな、と思い、ダッシュボードからプラグインの新規追加をクリックするとダッシュボードの上下それぞれに

Warning: session_start() [function.session-start]: open(/tmp/sess_a（略）, O_RDWR) failed: Permission denied (13) in /virtual/（略）/si-contact-form.php on line 1443
Warning: session_start() [function.session-start]: Cannot send session cache limiter – headers already sent (output started at /virtual/（略）/si-contact-form.php:1443) in /virtual/（略）/si-contact-form.php on line 1443

および

Warning: Unknown: open(/tmp/sess_a（略）, O_RDWR) failed: Permission denied (13) in Unknown on line 0
Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/tmp) in Unknown on line 0

とかエラーログが表示されている（固有の値かもしれないところは適当に略しました）。
なんじゃこりゃ。グーグル先生に聞いてみた。

参考（になったけど直接解決にはならなかった）
http://hudor.net/?p=483
http://faintdusk.com/bftsky/archives/29
http://blog.ipweb.org/archives/54
http://wordpress.server-domain.info/xrea/si_captcha_donot_work.html

色々見た感触としては、

• 原因はXREAのPHPがセーフモードで動いてること。（CGIとして動作させれば良いものの、今度は権限のほうで引っかかる？）
• /tmpフォルダを作ってsession.save_pathを指定すれば良いらしい
• メディアファイルのアップロード画面でも同じエラーログが出るらしい→確かに出た

ということなので、tmpフォルダを置いて、試してみた。

• php.iniを置く→効果無し
• .htaccessで→効果無し
• wordpressのconfig.phpにini_set( ‘session.save_path’ , ‘/virtual/ユーザー名/temp’);を追記

３つめのみ、プラグインの新規追加およびメディアファイルアップロード画面でエラーが出なくなった。

が、解決かと思いきや、今度はそれ以外の全ての画面で同様のエラー発生。ただしメッセージの（/tmp）がこちらで指定したパスに変化している。
tmpフォルダの権限を緩めてみたが駄目。
更にぐぐるも、解決策…というか症例が見当たらず。そもそも上に示したものもFast Secure Contact Formの話ではなくて、これ意外と誰も使ってないプラグインなのかな…目についたもの選んだだけなので人気かどうか検討してないんだけど；

で、色々見ている間に、作ったtmpフォルダの中にエラーメッセージ中にある「sess_a（略）」ファイルがいつの間にか生成していることに気付く（後の試行により、エラーを吐いたときに生成していることを確認）
「もしかしてフォルダまでは辿り着けたけどファイルにアクセスできなかったのでは」と思い、生成されたファイルの権限を緩めてみた。
→解決
全てのページでエラーが出なくなった。

その後更にいくつか条件を検討してみたところ、およそ次のような感触

• ・config.php内のsession.save_path指定は必要。（デフォルトのパスは少なくともxreaでは使えない）
• ・↑で指定したフォルダの属性はxx7、中のファイルsess_a（略）はxx6以上の権限が必要。
• ・他はどうでもいい

しかし「その他」に書き込みや実行の権限与えて大丈夫なの？というのが素人ながらちょっと心配。
せめて場所変えておこうということで、ルートじゃない適当な場所にフォルダ作ってsession.save_pathをそこへ指定してみたところ、同じファイルは生成したんだけど属性が変更できない。
なんで？と思ったら所有者がユーザーじゃなくてapacheになってる。
所有者を変更する方法がよく分からんかったので、ファイルを一旦ローカルにダウンロードして、apache所有のファイルを削除、アップロードし直すことによりユーザー所有の同一ファイルとなり、属性変更で今度こそ解決となりました。

結局理屈はよく分からんままですが、素人としては使えりゃ取り敢えず良いか、ということでここまで。
つかれた…
詳しそうな人に聞いた方が早かったかもしれんと思いつつ、どこまで一般的な問題なのか分からないので悩ましいところ。

今後似たようなことが起きたときのためにメモしておきます。

（12月12日）

案の定再発だよー。メモしておいて良かった(･ワ･)
FastSecureFormとCaptchaプラグインの更新が来ていたので自動更新してみたら類似の症状再発。

Warning: session_start() [function.session-start]: open(/virtual/（略）/sess_（略）, O_RDWR) failed: Permission denied (13) in /virtual/（略）/si-contact-form.php on line 1674
Warning: session_start() [function.session-start]: Cannot send session cache limiter – headers already sent (output started at /virtual/（略）/si-contact-form.php:1674) in /virtual/（略）/si-contact-form.php on line 1674

属性変更するんだよな→あれ？適用されてない→そうだった所有者apacheだから変更できないんだった。
ので、一旦DLしてUL…しようとするも、DLできない。Oh…そもそも前にDLできたのが不思議な気もするけど。

さてどうしたものかと試していたら、DLはできないけど削除はできることが判明。

よく分からんけど最終的に、phpをcgiとして動作させる.htaccessをsi-contact-form.phpのところへ置いて、該当のsess_（略）ファイル（所有者apacheで属性変更できない）を削除してダッシュボード表示すると何故か所有者がuserになって再生成していたのでFFFTPで属性変更して解決。.htaccessファイルが効果あったのかは不明。なぜ解決したのかも実際のところはよく分からず。

apacheって何？レベルの者が手を出すべきではないのかもと思いつつ、致命的なところではなさそうなので動いてればいいやという感じです。
理屈分かってる人が見たら失笑ものかもしれん。失笑しつつも優しく仕組みや理屈を教えてくれる方歓迎（ぉ

しかしこれ今後updateのたびに毎回やるのかい…うーん、やっぱちゃんとした解決法を学んだ方が良いような気がする。

（2012年1月8日）

問題そのものの「ちゃんとした解決法」ではないような気もするけど、「所有者をapacheからuserに変更する」手順についてはちゃんとした方法がありました。

WordPress が自動生成するファイルの所有者・パーミッションと、その変更方法

XREAの管理ツールにちゃんとそれ用のがあったとは…orz ぐぐったときには、他の鯖ではそういうの見たんですが、XREAには無いのかしら…としょんぼりしていたのに。
ここから更にリンク先のサポート掲示板によると、apacheで作られちゃったファイルは自動的かつ定期的にuser（707）に変更してくれているらしいんですが、どうもそうは思えないなぁ…

そして、「モジュール版PHPから作成されたファイルは、ユーザー名：apache となります。　これはモジュール版という仕様上、避けられません。 」とのことなので、根本的な解決策はないのかも。まぁ致命的な問題ということはないので良いんですけども。