年: 2005年

予想どおりのコメント

Amazonの「はじめてのPHP言語プログラミング入門」にやっと予想どおりのコメントが出てきました。

はじめての、というタイトルに惹かれ購入したのですが、ちょっと難しすぎるというのが正直な感想です。サンプルプログラムに説明のない単語があったり、解説文に聞きなれない専門用語があったり。他の言語や、別の本でPHPを学んでいれば問題ないのでしょうが、それだったら「はじめての」とか「入門」という言葉をタイトルに入れないほうがいいんじゃないかな、と思います。

著者が、博学なのはよく分かるのですが、書き手としては癖があります。掲載されているプログラム自体は簡単なのですが、解説が細かい事まで書きすぎてあり、読んでいて辛くなります。難しげな専門用語もサラリと出てきたりします。結果的に、初心者が読むには向いてないような気がします。PHP初心者には、細かい事を気にせず、ガンガン書いていくタイプの本をお薦めします。

ここで言い訳しておきます :)

この本を書いている時点で「基本は説明したので、とにかく書いてみよう、作ってみよう」と言うPHP入門書(ほとんどはWebサイト構築入門書の体裁)はいくらでもありました。多くのPHP入門書籍はWebサイトを構築する為のツールのような位置づけとしてPHPを説明していました。同じような本を書いてもつまらないので、あらたにPHPを言語として習得されたいプログラマ向け、というコンセプトで書いています。

「はじめての」を付けない方が良いのでは? と指摘されていますが、その通りかも知れません。「はじめての」と付いているのは、この本は当初、技術評論社の「はじめての」シリーズ用に書きはじめた為、「はじめての」と付いています。ページ数等の関係でシリーズ本としなかったのですが名前に残ったという経緯があります。言われてみると「PHP言語プログラミング入門」の方が良かったかもしれませんね。供給側の考えとしては「はじめて」PHPを「言語」としてとらえた入門書、という意図があったので「はじめて」と付いています。

まえがきでも多少ふれていますが、PHPをプログラミング言語としてある程度体系的に習得したい方向けに、プログラミング入門書ではなく言語の入門書として書いたつもりです。このため、本当に初めてプログラミングをPHPで習得したい方、とにかくPHPを使ってWebサイトを作ってみたい方、には不向きな書籍であるという評価は正しい評価です。ターゲットとしている読者は「他の言語は知っているから、PHPでプログラミングする場合に必要な知識や注意点を知りたい方」「とにかく作ってみようタイプの書籍でPHPを習得したが、PHPを言語としてある程度体系的に知りたい」方を想定しています。

出版社/著者からの内容紹介
 Webアプリケーション構築ツールとしてPHPを取り上げた書籍は数多くありますが、言語の解説・入門書としての書籍はあまりありません。
 本書は、プログラミング言語としてのPHPを解説することに最も重点を置いた入門書です。本書を通じて本格的なアプリケーション構築に必要な基礎知識を習得することができます。

出版社からのコメント
■こんな方におすすめ
・PHPプログラミングに興味のある方
・PHPをきちんと学びなおしたい方

と購入者の方に配慮しているつもりですが、Amazonで購入する場合は立ち読みをしてから買う事ができないのでタイトルのみで購入すると期待外れになってしまう場合があります。しかし、amazon.co.jpでもスキャナでスキャンしOCRでテキスト化したデータを検索できる「サーチ・インサイド・ブック」サービスがはじまるようです。「はじめてのPHP言語プログラミング」もこのサービスで立ち読みできるようデータベース化を許諾しています。しばらくすると立ち読みできるようになるのでタイトルから期待していた内容と違った、と言うことは少なくなるのではないかと期待しています。

ところで、書き手としては言語要素をさらっと解説してアプリの作り方を説明する方がかなり楽です。このような書き方の本の方が売れるようですが中身がある本の方が価値が高くなると信じてこのような内容になっています。Webシステム構築入門書としては適していないかも知れませんが、業務としてPHPを使う方には役に立つ内容と思っています。(と言うより業務でPHPを使う方には知っておいて欲しい知識を記載しています)ご意見/感想などはAmazonのコメント、Wikiメール、お好みの方法でお願いします!

SATAとPATAの混在環境

最近のマザーボートはSATAとPATA、両方のインターフェースが当り前のように着いてきます。しかし、LinuxでPATA、SATAのHDD両方が接続されている場合は簡単に構成できない場合が多いかも知れません。

Althon64のPCを組む為にASUS A8V Deluxeを購入しました。AthlonXP 2500+に接続していた80GBのHDD(/dev/hda – WindowsXPのみインストールされている)と200GB HDD(/dev/hdb – 各種Linuxのビルド・テスト環境がインストールされている)を
200GB (/dev/hda – 古い80GBのWindowsXPのパーティションのコピーとLinux)と250GB(/dev/sda – 古い200GBの各種Linuxビルド・テスト環境)に移行しました。

WindowXPのパーティションの移動はddコマンドで簡単に移動できます。今のHDDはLBAが当たり前でシリンダ数さえ合っていればddでデバイスからデバイスへコピーするだけで移動できます。CPUとマザーボードが変わりましたがXPからはWindows2000やNT様に苦労する事はありません。

苦労したのはLinuxのシステムイメージの移行です。PATAとSATAの混在環境にしたのですがブートに色々な問題が発生します。Linuxのブートプロセスはある程度知っているので、ほとんどは既に知っている問題だったのですがBIOSの設定とgrubの動作に手惑いました。

ご存知の通りLinuxはHDDの認識にBIOSを使いません。このため最初にgrubを起動したときとブート後のデバイスの順序が異なっていました。BIOSの設定とLinuxが認識するHDDのデバイスの順序が異なっていると混乱してしまいます。BIOSの設定をLinuxの認識順序と合わせる事ができるBIOSであれば、同じにすると問題を回避できると思います。Wikiには多少詳しく(?)記述しています。

分散リファラスパム

来ているところには前からアクセスがあったのだと思いますが、Botnetを利用したと思われるリファラスパム攻撃が急増しています。データベースに載せられたのかもしれませんね。

ソースIPが広範囲に分散しています。IPアドレスがばらばらなのでBotnetを利用していると思われるます。自分のネットワーク帯域ではないのでリファラスパムが有効かどうかも確認していないようです。

スパムメールの半分はBotnetから送られていると言われていますが、Webの帯域の半分はリファラ/コメントスパムのトラフィック、なんて事にならなければ良いのですが…

本当に面倒な世の中になりましたね…

WebCollege (xscreensaver) にご用心

xscreensaverにWebCollegeと言うスクリーンセーバモジュールがあります。Webからランダムにイメージファイルを取得しスクリーンに貼り付けます。このスクリーンセーバがインストールされている場合、

man webcollage

とするとこのスクリーンセーバのマニュアルページが参照できます。xscreensaverのデフォルト設定では「ランダムスクリーンセーバ」設定時にはWebCollageは使われないようになっています。それはこのスクリーンセーバがランダムに取得する画像にかなりの高確率で好ましくない画像が含まれているからです。

デフォルトで使用されないのに何故このような事を書いているか、というと私のデスクトップPCはKDEを利用しているからです。KDEを使っている場合、xscreensaverが提供するスクリーンセーバの仕組みは使わずに独自のスクリーンセーバ選択機構を使用しています。しかも、ランダムモードの場合どのスクリーンセーバを使わないか選択できません。つまりWebCollegeが使われるかも知れません。

このスクリーンセーバはRedHatやDebianでも問題になっています。

とにかく有害なスクリーンセーバを削除したい場合はrootになってから

locate webcollege | xargs rm -f

を実行しましょう。

参考:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=139513
http://www.jp.redhat.com/support/errata/RHBA/RHBA-2004-443J.html
http://www.jwz.org/xscreensaver/faq.html#kde
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23311683

XMLRPC for PHPにセキュリティーホール

Secuniaから”Highly Critical”レベルとされるアドバイザリが出ていたのでxmlrpc-epiモジュールのことかと思いましたが、このモジュール利用したPHPスクリプトライブラリの脆弱性でした。

http://sourceforge.net/projects/phpxmlrpc/

利用されている方は出来るだけ早くアップデートした方がよいようです。

allow_url_fopen

追記:
現在のPHPではリモートファイル読み込みを制御するphp.ini設定としてallow_url_fopen(URL等のファイルとして読み込むフラグ)とallow_url_include(URLなどをPHPスクリプトとして読み込むフラグ)があります。php://input(標準入力用のURL。Webアプリの場合、POSTリクエストなどが読み込める)もallow_url_include=Offでは利用できません。このためallow_url_include=Offの場合、リモートスクリプトからの読み込みを防止できます。

基本的には

  • allow_url_includeは常に無効(JSONなどでなくPHPスクリプトとしてリモートデータを読む、などの場合は局所的に有効化)
  • allow_url_fopenは全く必要ないなら無効

とすると良いでしょう。

PHPを使っている方はHTTP/FTP/SSH等のプロトコルでリモートサーバ上のファイルをローカルファイルの様に読み書きできる事をご存知と思います。この機能はphp.ini設定のallow_url_fopenディレクティブで有効/無効を設定できるようになっています。PHP 4.3.4より前のPHPではこの機能のスクリプト中からも無効/有効に設定を変更する事ができました。(INI_ALLの設定項目であった)

驚いたことにPHP 4.3.4からphp.iniからしかこの設定を変更できなくなってしまいました。(INI_SYSTEMの設定項目になった)誰かがセキュリティ強化を目的として変更したのだとは思いますが、セキュリティも強化できず、有用なリモートファイルアクセス機能も使えなくする非常に拙い変更です。

例えば、phpBB(BBSアプリケーション)ではinclude/require文に不適切に処理されたユーザ入力が利用されている為、リモートスクリプトを読み込み実行できてしまう非常に深刻なセキュリティ上の問題がまた最近見つかりました。phpBBはallow_url_fopen機能が無効であっても動作するので

allow_url_fopen = Off

と設定するか必ず読み込まれる設定ファイルで

ini_set(‘allow_url_fopen’, 0);

とすると、phpBBのようなアプリケーションでも比較的安全に運用することができました。

しかし、allow_url_fopenがINI_SYSTEMの設定項目になった為、前者の方法を取ると他のアプリケーションで、場合によっては非常に有用な、allow_url_fopen機能を使えなくなってしまいました。後者の方法は、特定のアプリケーションのみの設定を変更するのに有効ですが、INI_SYSTEM設定項目であるため実際には無効に設定できなくなってしまいました。

セキュリティ上の意味は容易に理解できるであろうと、internals@list.php.net にallow_url_fopenの設定を

デフォルトOFF
INI_ALLへ変更

するように提案して見たところ議論が結構荒れています…
この設定が安全かつ不必要な機能制限が無く、最も良い設定と思うのですが…

# allow_url_fopen_includeのようにinclude/require文用の設定
# を追加するのも良いですが、デフォルトOFF、INI_ALLであるべき
# と思います。

php-rast

Rastとはネットワーク応用通信研究所が開発している全文検索システムです。

本ソフトウェアは,あらかじめ対象となる文書群から検索に必要な情報を格納するデータベースを作成しておき,それに対して検索を行う全文検索システムです.

検索方式は N-gram 方式や分かち書き方式から選べます.また,必要に応じて文字列処理モジュールを差し替えることができます.

なお,本ソフトウェアは IPA の平成16年度オープンソフトウェア活用基盤整備事業の委託を受けて開発を行っています.

このRast用のPHPモジュールを冨田冨田隆三さんが公開されています。

名古屋市立大学の冨田です

以前、全文検索エンジンRast のモジュールを公開したところ、ここでライセンス違反の可能性を指摘されて公開を止めていましたが、Rast-0.2.0 で BSD ライクな緩いライセンスに変更されたようなのでまた公開してみます。

ダウンロードはこちらからどうぞ。
http://a157.debian.co.jp/php_rast/

冨田

サンプルの動作は良い感じです。サンプルコードもざっと見てみましたが使いやすそうです。

Momonga LinuxとFedora Coreパッケージの比較

前にMomongaLinuxとFedoraCoreのパッケージの比較を行うスクリプトを作っていたのですが更新対象をFedoraCore 3からFedoraCore 4に変更しました。

http://www.momonga-linux.org/~yohgaki/compare_distribution_srpm.php?type=src_only

ついでにMomongaLinux 2とMomongaLinuxのtrunk(開発版)との違いも比較できるURLも用意しました。

http://www.momonga-linux.org/~yohgaki/compare_ml2_vs_devel.php?type=src_only

この比較リストの作成は時間がかかるのでキャッシュを使っています。確かキャッシュの有効期限は6時間くらいに設定していたと思います。最後に更新されてから6時間以上経過するとリストを再作成するので運が悪いとページの表示に時間がかかります。

“最強”のシワ対策品が登場へ!

シワは紫外線や加齢などによって起こるが、医師による治療を受ける以外に、シワを減らす有効な対策はなかった。

という事らしい。世の中には多数のシワ対策化粧品が販売されていると思いますが効果が無いのでしょうか?効果が有る化粧品も多いような気もしますが、どうなんでしょう?「レチノイン酸d-δ(デルタ)トコフェリル」という成分が効果的らしい。

3カ月後の結果では、シワの本数が1本以上減ったのが69%、毛穴の数や総面積も減少した。一方で、角質水分量は63%で改善した。

「これくらいの効果で最強であれば、今まで販売されてきた化粧品はどうだったんだろう?」と考えさせられました。

不正なJavaScriptによるダイアログの表示サンプル

先日IEの仕様ですに書いた問題とはどういう物か、百聞は一見にしかず、実際に見るのが良いと思います。

Secunia(ここからのアドバイザリは多いですね)がレポートした問題で、この不具合の動作をテストするページも用意されています。どういう訳かニュースサイトなどではこのURLが紹介されていない場合が多いようなので紹介する事にします。

http://secunia.com/multiple_browsers_dialog_origin_vulnerability_test/

このページの

Start the test:
Test Now – Left Click On This Link

「Left Click On This Link」を未対策のブラウザでクリックするとパスワード入力を要求するダイアログが開きます。

ポイントは「Left Click On This Link」は http://www.google.com/ にリンクされていること、クリックした後のダイアログ表示動作がいかにも http://www.google.com/ からのダイアログの様に表示されてしまうことです。どんなにセキュリティに精通したWeb開発者がWebサイトを開発してもこの攻撃に対処できません。ブラウザ側の問題だからです。
# 「このサイトはポップアップを利用していません」と注意を促すことは
# できますが、対策とは言えないでしょう。

これにユーザが騙されるか? というリスクへの対策が今問われています…
送信元が不明なダイアログやWindowの利用は注意してください、と言うだけでは不十分であること明らかではないでしょうか?

しかも、この問題を悪用するのは簡単です。
ほんの少しJavaScriptを知っていれば誰でも悪用できます。

IEの仕様です

最近話題になっている、信頼できるサイトからのダイアログの様に見せかける事ができるためフィッシングに利用される可能性がある問題、に対するマイクロソフトの対応です。

仕様として見て見ない振りしても問題は消えません。また一つIEを使わない理由が増えましたね。


成人の6割以上が銀行預金残高を主にインターネットで確認–米調査
という状況を考えると「仕様です」と言って切り捨てる訳には行かないと思います。

ブラウザのメンテナンスが大変であればいっそ「IEはもう新しいバージョンはリリースしません」と宣言してしまえばよいのではないかと思います。

_php_stream_passthru

php-usersのMLに投稿した内容の補足です。コードはPHP 4.4の開発ブランチのソースです。

main/stream.cに_php_stream_passthru関数が定義されています。reafile関数(ファイルの中身を全て出力)、fpassthru関数(ファイルリソースの中身を全て出力)に利用されています。

PHPAPI size_t _php_stream_passthru(php_stream * stream STREAMS_DC TSRMLS_DC)
{
    size_t bcount = 0;
    int ready = 0;
    char buf[8192];
#ifdef HAVE_MMAP
    int fd;
#endif

#ifdef HAVE_MMAP
    if (!php_stream_is(stream, PHP_STREAM_IS_SOCKET)
            && stream->filterhead == NULL
            && php_stream_tell(stream) == 0
            && SUCCESS == php_stream_cast(stream, PHP_STREAM_AS_FD, (void*)&fd, 0))
    {
        struct stat sbuf;
        off_t off;
        void *p;
        size_t len;

        fstat(fd, &sbuf);

        if (sbuf.st_size > sizeof(buf)) {
            off = php_stream_tell(stream);
            len = sbuf.st_size - off;
            p = mmap(0, len, PROT_READ, MAP_SHARED, fd, off);
            if (p != (void *) MAP_FAILED) {
                BG(mmap_file) = p;
                BG(mmap_len) = len;
                PHPWRITE(p, len);
                BG(mmap_file) = NULL;
                munmap(p, len);
                bcount += len;
                ready = 1;
            }
        }
    }
#endif
    if(!ready) {
        int b;

        while ((b = php_stream_read(stream, buf, sizeof(buf))) > 0) {
            PHPWRITE(buf, b);
            bcount += b;
        }
    }
    return bcount;
}

注目すべきは以下です。

            if (p != (void *) MAP_FAILED) {
                BG(mmap_file) = p;
                BG(mmap_len) = len;
                PHPWRITE(p, len);
                BG(mmap_file) = NULL;
                munmap(p, len);
                bcount += len;
                ready = 1;
            }

PHPWRITEマクロは最終的に出力バッファに書き出します。PHPからの出力は最終的にWebサーバにバッファされる場合があります。つまり、一度に大量のデータを出力するとメモリを大量に必要とする可能性があります。

Momoery Mapped I/Oの利点がバッファ無しでデータを読める事は分りますが、大きなファイルを送信するには不適切な事は明らかです。データを適切なチャンクサイズに区切ってPHPWRITEに書き込むよう変更しなければならないですね…

DokuWiki

久しぶりにmadwifiの設定をしようとmadwifiのページを見てみると見慣れないWikiを使っていたのでどんなWikiかさらっと見てみました。インストールやソースを読んでいないので見てみた感想です。

基本的なWiki機能はそろっているようです。ページの場所 “top>a page>another page”の様に表示されるのも便利です。ログインユーザ登録もサポートしているようで、Eメールアドレスを登録してから編集を許可する、という運用ができるのはSPAM対策やセキュリティ対策に役立つと思います。

次のような機能を持っているようです。

DokuWiki Features here

* works on plain text files, no database needed
* simple syntax and easy editing with quickbuttons and accesskeys
* Section Editing allows you to edit small parts of a page
* automatic generation of content tables
* unlimited page revisions
* colored side by side diff support
* support for read only pages
* syndication of recent changes as RSS Feed
* namespaces
* Interwiki Links
* uploading and embedding images
* image caching and resizing
* easy navigation through breadcrumbs
* Customizing with templates and plugins
* Multilanguage Support
* Spam blacklist
* custom text replacements
* pagecaching
* locking to avoid edit conflicts
* full UTF-8 support
* and more

Wiki機能の比較は見るだけでも興味深いと思います。

Tipsのページを見てみると色々な機能が追加できる事が分かります。SVGをPNGやGIFに変換、ページをPostscriptに変換、HTMLからDokuWiki形式への変換方法が記載されています。

面白かったのはNanoWebをサポートするWebサーバとして記載されている所です。NanoWebはPHPで記述されたWebサーバで

Nanoweb’s main features are :

– HTTP/1.1 compliance
– Powerful and easy configuration
– Modular architecture
– FastCGI, CGI and Server side includes support
– Name and port based virtual hosts
– Access control lists
– htpasswd, MySQL, PostgreSQL and LDAP authentication support
– Themes for server generated content
– Apache compatible log format, MySQL logging
– Directory browsing
– inetd support and SSL via external helpers
– Denial of Service protection
– Proxy Server extension
– Filters and gzip support
– RBL support (mail-abuse.org)
– Extension Protocols (request methods) support
– … and a lot more

と色々盛り沢山です。

コマンドラインのPHPさえインストールされていれば自分でWebサーバを立てる事ができます。NanoWebのソースは以前に読んだ事があるので多少は分かります。pluginの作成は簡単そうでした。速度的にも普通(?)のリクエスト数であれば十分処理できるパフォーマンスでした。(思ったより速くて驚いたと思います)