2007/11/20

Toxic

すっかり間があいてしまいました。気がついたら冬です。beatsync.net的には寒くて外に出たくないので家でプログラムを書いたりサイトのリニューアルをしたりする季節です。そろそろ手をつけるか…。

さて、今日のタイトルにもなってますがToxicというBritney Spearsの曲に11月頭あたりからハマっています。ブリトニー・スピアーズといえばお騒がせブリちゃんというようなイメージしか無かったんですが、ToxicいいよToxic。

この曲自体結構昔の曲になる(Album "In the Zone" Released 2004/01 in US)ので、まぁお騒がせブリちゃん的なイメージが定着する前の曲という感じではありますね。ちなみに酔っぱらって2日だけ結婚してたのがちょうど2004年1月ですか。

まぁなんでそんなところに行き着いたのかというと適当にWebをうろうろしてたらPVにぶち当たったという話でして、YouTubeにあったりするのでどんなのだよって気になる方は見てみてはいかがでしょうか。いやホントこのPVのブリトニーと比較してしまうと「エロかわいい」とかいって微妙にブームになった倖田來未がすごくかすんで見えます。一部の倖田來未バッシングがわかるような気がするわ。

で、実はブリトニーの新アルバムが先週でてるんですよ。いやー買うか迷うのなんのって。今回のブリトニー同様、2年ぐらい前?に同ジャンル(洋楽ダンスポップ)のKylie Minogueにハマってしまったときは結局5〜6枚ぐらいCDを買いあさってしまったので、今回も結構心揺れてる今日この頃なのでした。

だれでも編集可能を売りとするPukiWikiでアクセス制限とかしないほうが

さて話はかわって、仕事のほうはというとなんだか開発が終わったはずなのにあんまり終わった気がしないような感じの日々です。

ところでうちの部内用のWiki(PukiWiki使用)があるんですが、今日たまたまそれを眺めてたらそいつのアクセス制限で不味いところを見つけてしまいました…。自分としてはPukiWikiのアクセス制御ほど当てにならないものは無いと思ってるんで、なんか見つけても「まーそんなもんだよね」とか思うだけでいつも終わりなんです。情報を知るということにも責任が伴うので、見えちゃいけない情報が見える可能性に気がついても見なければいい話なんです。見てないということはログに何も残っていないということで証明できますから(軽く悪魔の証明だけどさ)。

学生時代にも研究室内の情報共有がPukiWikiだったので、自分もプラグイン作ったりしてて、いろいろカスタマイズするには便利なのはよく知ってます。が、研究室の外部向けページとか、学科のサイトとかにPukiWikiを採用しようというプロジェクトが実行されたときは第三者としてかなりセキュリティ面に気を使ったものでした(実際2,3個アクセス制限のすり抜け方を見つけたので教授に教えたりとかしました)。

で、今回はなんか管理職専用情報も同じWiki上で単にPukiWikiのアクセス制限に頼るだけで運用されてるので、今回見つけちゃった手法を使ったら管理職じゃない人でもその情報入手できるじゃんとかいうレベルの問題なんですよ。まぁたいしたことのない情報しか書いてないなら別にどうでもいいんですけど、そんなこたーないだろうと思うので、しかたなく明日にでも部長にこっそり言ってみることにしました。面倒だなぁ。

面倒ではあるけれど、そういうのを見つけたまま放置して今後なんかあったときに疑われるのはとってもイヤ。だからといって「こんなことをすると情報の入手が可能な状態になってますよ」と内部の人間が上司に対して教えるのもそれはそれでなんとも嫌な気分ですね。そういう意味でも「誰でも自由に編集できる」ことを売りにしてるPukiWikiで複数レベルのアクセス制御をやろうとするなよなーとは思う今日この頃です。Wikiを分ければいい話なのに。

ちなみにどの辺がまずかったのかというと、根本的にはPukiWikiの構造上の問題で、アクセス制御をするのに使ってるcheck_editableとかcheck_readableっていうPukiWikiのライブラリ関数を「プラグインが実行する必要がある」というやつなんですよね。

これってつまりプラグインがcheck_*ableを呼ぶのを忘れるとふつーに読み込み/書き込みできるという意味ですよね、たぶん。だから、うっかりプラグイン作成者がこのcheckをしないプラグインを作っちゃったりしたらそれがアクセス制御上の懸念になるわけです。そういうことであれば、プラグインを呼び出す側(lib/plugin.php)でプラグインを呼び出す前にその手のアクセス制限チェックをするべきなんです。設計としてはね。

でも、これを今のPukiWikiに実装しようとすると話は結構面倒で、「editable/readable」という2種類のアクセス制限レベルがあるせいでこれをプラグインを呼び出す側が「readするだけなのか、それともeditも行うのか」という情報を呼び出し元に通知する仕組みをつくらないとプラグイン側にとってフェイルセーフなアクセス制御システムが構築できないんじゃないかなと思っています。

まぁ、PukiWikiのアーキテクチャについては素人同然(いまこの記事書くために該当部分のソースをちらっと読んで仮説が正しいか確かめただけ)なので、もしかしたらもっとうまい解決方法があるのかもしれませんが、一番いいのはやっぱり「誰でも編集可能」っていうWikiの本質から一歩踏み外すようなページレベルでのアクセス制限はさっさと窓から投げ捨ててしまえばいいのになーという所でしょうか。

というわけで、なんか久々の更新だったのでつっこんだテクニカル駄文を書きたくてしかたなかったのでだらだらと書いてみてしまいました。

具体的にどのプラグインで問題だったのかという点についてですが、すいません、これはとりあえず明日うちの部のほうのWikiで対処してもらってからということにさせてください。セキュリティ問題を暴露するのが目的の記事ではないんです。

デリケートな話題ではあるのですが、こんな問題を見つけたけど、アーキテクチャを推測したら設計上の問題に分類されそうだけど、そもそもWikiというツールの性質からして矛盾してることをしようとしてるんだからこういう設計上の問題がでてくるんだろうね〜という個人的な所感を述べた記事なので…。

ちなみに、念のためPukiWikiのBugTrackを探してたら実は2年ぐらい前からある既知問題で、パッチは提示されてるけどCVSには入ってないみたいでした。パッチ自体はBugTrackに記述されてるので、とりあえず部長にはこのBugTrackを通知してみます。はい。

実はいつものように最後にバッサリ切って捨てるような所感も書くには書いたんだけど、それが主張のポイントってわけじゃなくて、この記事の主眼はあくまでも「目的に矛盾する機能を入れて設計上の問題がでるケーススタディとしては面白い話題だねー」というところなので、所感の部分についてはおとなしくしておくことにしました。あぁ会社ってむずかしいなぁ。