adiary開発日誌

Ver2.12に対しバグ修正を行いました。

ダウンロードはこちらから。

■Ver2.12→Ver2.13の変更点

• コメント欄付近に埋込テキストをおけるようにしました。
• カテゴリリスト/月リストを「開いて表示」設定が無効になっていたので修正しました。
• 携帯表示のコメント欄関連の処理のおかしいところを修正しました。
• コメント投稿成功時に表示されるカレンダーが過去のものになることがあるバグを修正しました。
• メール投稿にて「Content-Transfer-Encoding: quoted-printable」に対応しました。
• Ver2.06以降の中間拡張子の許可機能で、標準の設定では test.php5.pdf などがアップロードできてしまう問題を修正しました。
• <$v.phone_kantan_disable=1> を設定すると、かんたんログインを無効にできるようにしました。(Request by asano)
• １度に２通以上のメールがたまった状態でpopからのメール投稿が行われると、月別リスト表示が通常と異なるバグを修正しました。（Thanks to ひとぅ）

■Version2.00（β含む）以降からの乗り換え

• そのまま上書きしてください。
• Ver2.11以前の場合、uploader.conf.cgi をサンプルから再生成してください。*1

なおVer2.06よりアルバムシステム関連のJavaScriptの置き場が変更になっていますので、紛らわしい場合は theme/*.js を消してから上書きしてください。

アップデート方法の参考情報。

■Version1.44以前(C73/2.00α含む）以前からの乗り換え

Version2.00への移行処理を先に行ってください。

今はかんたんログイン脆弱性がブームなようです。今更何言ってるんだという感じですが、一応adiary内部でどのようにかんたんアクセスを処理しているか書いておきます。

• かんたんログインとは
• adiaryの実装
• しかし別の問題が……
  • とりあえず

■かんたんログインとは

携帯の機種固有IDを使用した自動ログイン機能のことです。Cookieを実装する気のない某殿様商売通信キャリアの存在が一気に利用を広げました。

機種固有IDは、USER-AGENTなどのHTTPヘッダによって送信されます。HTTPについて知っている人ならすぐわかることですが、このヘッダは誰でも簡単に任意の値で送信することができるため何のセキュリティにもなりません。例えるなら、掲示板に書き込む際の名前欄で承認しているようなものです。しかも比較的単純な通し番号なので、秘匿性もあったものではありません。*1

■adiaryの実装

もともとこんな危険なものを実装する気はなかったのですが（苦笑）、要望があったのでしぶしぶ実装しました。

右の画面がかんたんログインの実際の画面です*2。このページをブックマークしてもらい「かんたんログイン」をクリックしてもらうことでログインできます。

ID:useridの人がかんたんログインを設定したこの画面のURLは次のようになります。

http://〜/adiary.cgi/=userid:LE0GdeSwSdQ/?login_docomo

LE0GdeSwSdQという文字列は「機種固有IDから生成されるハッシュ」です。adiary.conf.cgiの中の

<$Secret_phrase = '秘密の言葉'>

の設定が漏洩しない限りハッシュ文字列を第３者が知ることはできません。

仮にこのログインURLだけ漏洩しても、対応する機種固有IDが分からないとログインできません。ですので、いわゆるかんたんログイン脆弱性はadiaryには存在しないことが分かります。

■しかし別の問題が……

次は携帯ログイン後のURLです。

http://〜/adiary.cgi/=userid=kpQYloloFFF0M4Xnujjs/?login_docomo

「kpQYloloFFF0M4Xnujjs」がセッションIDになります。Cookieが使えないので仕方なくURLに埋め込んでいるのですが、リファラーからこのURLが漏れるとセッションが乗っ取られてしまいます。

ドコモはリファラを送らないことになっているみたいですが、他機種だと色々で頭の痛い問題です。

（参考）携帯電話向けWebアプリケーションのセッション管理手法

とりあえず

Cookieを食わせて、食べられたらそっちに誘導するように変更するか……。Cookie非対応でリファラ送信なんて機種もあるそうですが、それは端末脆弱性なんで無視かな。

以前の構想をアップデート。

■adiary本体

この先１０年耐えるシステムを目指して設計します。

• JavaScript必須。jQueryの採用（prototype.jsは却下の方向）
• HTML5の採用。管理に必須とする。表示はHTML4のスケルトンも用意する。
• IE6/7を完全に切り捨て。*1
• CMSとしての機能の強化。
• プラグインシステムの採用。
• 記法のはてなとの細かい互換性切り捨て。*2
• 画像管理機能の本体統合と作り直し。*3
• Perl 5.8か5.10以降必須に。*4

現状でもCMSとして企業ブログや企業サイトで使われていたりするのですが、いかんせんCMSとしては扱いにくい部分があるので申し訳なさでいっぱい。

もともと古いadiaryのソースコード（+スケルトン）をベースに書き直す予定でしたが、あちこち依存してて書き直しが厄介なので*5時間がかかっても１から書きなおします。*6

Satsuki-systemもRoRのような開発環境整備をしたいのですが、ドキュメントを取りまとめるのにadiary V3を使いたいという本末転倒状態（笑）

CGI開発中についうっかり無限ループを生成するなんて経験のある人も多いと思いますが、つい最近２回連続でサーバごと落としてしまったので*1本格的に対策しました。

■RLimitMEMとRLimitCPU

ApacheにはもともとCGIのメモリやCPU使用量を制限する設定があります。それがRLimitMEMとRLimitCPUです。

それぞれ「メモリ（リソース）使用量」と「CPU時間使用量を制限する」もので、制限値を超えた瞬間にプロセスを殺してくれます便利なものです。*2

# 256MB limit（unit Byte）
RLimitMem 268435456
RLimitCPU 30

もちろんこれは設定していたのですが……。

■RLimitMemが効かない

top コマンドで監視していいたら普通に500MBのメモリを食ってます。どうやら、RLimitMemやRLimitCPUが効かないようです。

• mod_perl / mod_perl2
• FastCGI(mod_fastcgi) / mod_fcgid

では効きません。ちょうどmod_fcgidを使用していました。Perl自体は別プロセスで起動しているので効くのかと思ったのですが、どうやら無効なようです（汗）。ちなみに通常CGIの他、SpeedyCGIは効きます。*3

■Apache自体に制限を掛ける

Apache自体のメモリ消費量に制限をかければ、万が一無限ループなどで暴走してもサーバ落ちを防ぐことができます。Apache自体は落ちてしまいますが、サーバが落ちるよりは100倍マシです。

Apacheの起動スクリプト（シェルスクリプト）に

# 1GB limit（unit KByte）
ulimit -v 1048576

と記述することで制限を加えることができます。

Ubuntu/Debian系の場合は /etc/apache2/envvars に ulimit を書き加えればよいようです。これでApache自体が落ちると思ったのですが、mod_fcgid の場合 fcgi プロセスのみが落ちてくれました。

ちょっと謎は残るけど、とりあえず目的は達成したのでこれで。

Webアプリ開発中に ImageMagick（perlmagick）が SpeedyCGI 環境でまともに動かない不具合に当たりました。

• 問題の詳細
• 問題の症状
• 問題の原因
• 問題の解決法？？
• まとめ
• メモ

■問題の詳細

• Image::Magick をロードして何かしら処理を行うルーチンを SpeedyCGI で実行する時、２回目以降のキャッシュされた状態で不具合が起こる*1。
• 問題確認環境
  • Perl 5.8.8 + SpeedyCGI 2.22
  • ImageMagick 6.3.7 および 6.5.9

この問題は FastCGI や mod_perl2 では起きません。

■問題の症状

スクリプト

#!/usr/bin/speedy

use Image::Magick();

print "Content-Type: text/plain\n\n";
print "Image::Magick Version $Image::Magick::VERSION \n";
my $image = Image::Magick->new;
$image->Read( 'x.png' );
}

実行結果。

~$ test.pl
Image::Magick Version 6.3.7
~$ test.pl
Segmentation fault

~$ test.pl
Image::Magick Version 6.5.9
~$ test.pl
Segmentation fault

■問題の原因

不明。

■問題の解決法？？

ENDブロックを呼ばれないようにして終了時のメモリ開放はOSやPerl自身に任せる。

#!/usr/bin/speedy

use Image::Magick();
sub Image::Magick::END {}

print "Content-Type: text/plain\n\n";
print "Image::Magick Version $Image::Magick::VERSION \n";
my $image = Image::Magick->new;
$image->Read( 'x.png' );
}

たしかにこれで問題は起こらなくなるのですが、

$image->Write( 'x.jpg' );

をするだけでダメになる。とにかくメモリリークっぽい挙動ですが、詳細が不明の挙動不明で、試行錯誤の末 Image::Magick をロードするダミーモジュールを作成しましたが、これで回避できるケースと回避できないケースがあり暗中模索。

• ImageMagick.pm

  use strict;
  package ImageMagick;
  sub new {
  	require Image::Magick;
  	return Image::Magick->new;
  }
  

• main.pl

  use ImageMagick();
  my $img = ImageMagick->new;
  #
  # $img は Image::Magick のオブジェクトであるので、
  # Image::Magick と同様に利用できる。
  #
  

■まとめ

gccの（ライブラリlibgomp ）バグのようです。gcc 4.3より前のVersion（4.2以下）で、amd64環境の時起こる模様。

■メモ

256色png（8bitカラーパレット）で保存する方法。

$image->Read( 'x.png' );
$image->Resize(width=>133, height=>100);
$image->Quantize(colorspace=>'RGB',colors=>256);
$image->Set(depth => 8); 
$image->Write( 'y.png' );