Kenichi Maehashi's Blog

脳内コアダンプ

RSS
Category: Linux
自分のリポートがキッカケになって、Red Hat の Bugzilla に Bug 591293 が登録されました。
けっこうハマりやすいポイントだと思うので、注意喚起を兼ねて記事を起こしてみます(ここで書いてもあんまり読まれないけど...)。

問題の概要

以下の全てを満たす場合:
  • Red Hat Enterprise Linux 5 (または CentOS 5.x などの RHEL 互換 OS) または Fedora を利用している。
  • ディストリビューションの提供する(yum リポジトリの)httpd (バージョン 2.2 系) パッケージを利用している。
  • /etc/httpd/conf/httpd.conf に以下の記述がある(デフォルトのまま編集していない場合など)。
    <Files ~ "^\.ht">
    Order allow,deny
    Deny from all
    </Files>
  • Satisfy Any ディレクティブを .htaccess あるいは設定ファイル(/etc/httpd/conf.d/*.conf)で使用している。
この場合、Satisfy Any の設定をしているディレクトリ以下にある .ht で始まるファイル(.htaccess, .htpasswd, .htdigest, ...)がユーザから閲覧できるようになっている可能性があります。

Satisfy Any とは何か

Satisfy Any ディレクティブを使うと、「Order」による IP アドレスベースのアクセス許可と「Require」によるユーザ認証ベースのアクセス許可を OR 条件にすることができます。
例えば、「ローカルのネットワークであれば常にアクセスを許可するが、それ以外ではパスワード認証が必要」というポリシーを実装したいとき、.htaccess に以下のように記述することができます。
# ローカルネットワークからのみ許可
Order deny,allow
Deny from all
Allow from 192.168.0.0/16

# ユーザをパスワードで認証したときのみ許可
AuthType Basic
AuthName "Members Only"
AuthUserFile "/var/www/.htpasswd"
Require valid-user

# Require または Allow のどちらかを満たせばよい。
Satisfy Any
このとき「Satisfy Any」は、「もし Order ディレクティブの条件を満たしたら Require 不要でアクセス許可。ただし、Order ディレクティブの条件を満たさなくても、Require のユーザ認証が通ればアクセス許可」という動作をします。ここで .htaccess ファイルにアクセスした場合、
  1. httpd.conf にある Order ディレクティブによって、アクセスは Deny from all される。
  2. Order ディレクティブの条件を満たさなかったので、.htaccess に書かれた Require ディレクティブでユーザ認証を行う。
  3. ユーザは、自身のユーザ名とパスワードでその認証を通過する。
  4. Order は満たさないが Require は満たされたので、.htaccess ファイルへのアクセスは許可される。
… というように、見えてはいけないはずの .ht* ファイルが見えてしまいます。“あなたの予想に反して、このページが見えているでしょうか?”とか訊いてる場合じゃないですよ。

対策

/etc/httpd/conf/httpd.conf に書いてある上記の設定に、
<Files ~ "^\.ht">
Order allow,deny
Deny from all
Satisfy All
</Files>
と「Satisfy All」を加えれば大丈夫になります。これは Apache の Web サイトからダウンロードできるソースコードに添付されているサンプル httpd.conf と同じ設定です。

おまけ

セキュリティ脆弱性ではないと思った(なぜなら Apache の仕様通りの動作だから)のですが、Bugzilla に登録するのが面倒だった :-) のと、いきなり Bugzilla に晒されるに耐える英語を書く自信がなかったので、Red Hat Security Response Team にメールしてみました。

この問題は 2008 年頃に気づいていたのですが、昨日別のサーバで同じ問題でハマってしまい、「デフォルトがこの設定なのは危ないな」と思った次第。興味のある方がおられるかもしれないので、送ったメール全体を掲載しておきます。
Subject: RHEL5/6 httpd - insecurely configured

Dear Sirs or Madams,

I'm not sure this is a security issue or not, but I found that "httpd"
package in RHEL5 / RHEL6 Beta is configured insecurely by default.

In "httpd.conf" file in the package, there is a <Files> directive
that makes .ht* files invisible:

------------------------------------------------------------------------
<Files ~ "^\.ht">
Order allow,deny
Deny from all
</Files>
------------------------------------------------------------------------

This is insecure when used with "Satisfy Any" directive. For instance,
if you place .htaccess file like this in the DocumentRoot (assuming
"AllowOverride AuthConfig"):

------------------------------------------------------------------------
# Allow access from the local network:
Order deny,allow
Deny from all
Allow from 192.168.0.0/16

# Require authorization if accessed from outside the local network
AuthType Basic
AuthName "Employees Only"
AuthBasicProvider ldap
AuthzLDAPAuthoritative on
AuthLDAPURL ldap://localhost/dc=example,dc=com
Require valid-user

# Need to satisfy any of "Allow" or "Require"
Satisfy Any
------------------------------------------------------------------------

If a user passed the authorization using his username and password, all
"Order" directives will be ignored because "Require" directive is
"Satisfied"; as a result, .ht* files become visible to the user.

Since the use of "Satisfy Any" is a very common way to control access
policy, and such .htaccess files often contain sensitive information
like AuthLDAPBindPassword, I would like to ask you to change the default
configuration to:

------------------------------------------------------------------------
<Files ~ "^\.ht">
Order allow,deny
Deny from all
Satisfy All
</Files>
------------------------------------------------------------------------

This is also the default configuration of httpd.conf in the source
tarball from Apache, as of httpd-2.2.15.

Yours faithfully,

Kenichi Maehashi
およそ 1 時間後くらいに、「セキュリティアップデートとしてリリースする必要があるとは思わないけど、尤もだと思うから Bugzilla しておくよ」というような意味の返事が来ました。お仕事早いです。
Category: Apple
電池 3 本モデル(現行モデルは電池 2 本)の Apple Wireless Keyboard (JIS) で、右のコマンドキーを押しながら左右の矢印キーを交互に連打すると、接続が切れてしまう。左のコマンドキーだと大丈夫だし、他のキーの組み合わせでは発生しない。今のところ再現率 100% なのですが、これは firmware の bug なのだろうか。もしかして Apple の故障診断用の裏コマンドとか?

ちなみに接続先は iMac (MB418J/A) です。
Category: Computer
こんな感じの検索画面を作ってみました(クリックで拡大)。
肯定・否定・アイディアなど何でも、コメントに書いていただけると嬉しいです。

ボタンが無くなった操作は、Return (Enter) キーで検索、Esc キーで中止、ダブルクリックでダウンロードです。

Mac ユーザからの評価は今までよりは良い気がする。Windows ユーザには… 受け入れて貰えるだろうか。
近いうちに ML でアンケートをお願いするかもしれません。
Category: Apple
というわけで、話題の Thoughts on Flash の完訳です。英語スキルアップのためには努力を惜しみません。誤訳があればご指摘をいただけると嬉しいです。適宜 revise しているので言い回しは reload するたびに変わるかも :-)

クロスプラットフォームの開発ツールについては、全くもって仰る通りなんだけれども、それでも開発者がツールを選ぶ自由というのはあるべきだと思う。要するに何が言いたいのかというと、REAL Studio (REALbasic) で iPhone / iPad アプリを作ることの可能性がほぼ閉ざされていることへの絶望感です(Flash 自体にはあんまり興味ない)。

Flash を切ること自体は Apple が今までにやってきたことと似たスタンス(ADB から USB とか)だけど、力押しで Flash を消せるかというのは個人的にかなり疑問。もはやインフラになっている部分もある。例えばサーバとの object の交換とかは JS だと難しいと思う(Flash Remoting のように)。JSON 使えば良さそうではあるけれども、互換性のある技術ではないし Flash からの直接移行は難しい。Flash エンジニアというのが職業として成り立ってることや IE がトップシェアを握っていること(ブラウザ間の互換性問題)などなど、Flash を Web から消すのはだいぶハードルが高い感じ。あと iPad 向けと PC 向けでセパレートな Web が展開されちゃうとガラパゴス再来で残念な感じになるだけなので避けてほしいな。

ついでに余計なことを言うと、先日 iPad を触らせていただく機会があったのですが、あれだけディスプレイが大きいと実現できることのスケールがだいぶ違うなという印象。Google Street View なんて、まさにその場にいるような臨場感でした。できるだけ多くの人に触ってほしいデバイスです。たぶん想像してるよりもずっと未来を感じると思う。個人的にはお絵描きアプリの指先ツール(絵を滲ませるやつ)が最高に興奮しました。


Flash に対する考え


Apple は Adobe と長期間に渡る関係があります。実際、私達は Adobe の創業者と、あの有名なガレージで既に会っていました。Apple は Adobe にとって最初の大きな顧客で、私達は彼らの Postscript 言語を Laserwriter プリンタに採用しました。Apple は Adobe に投資しており、長い間、会社の 20% 程度を保有していました。両社はデスクトップパブリッシングの先駆者として一緒に働き、良好な関係を保っていました。しかし、その後両社は別々に成長してゆくことになります。Apple はほとんど瀕死に近い経験をし、Adobe は Acrobat 製品で企業向け市場に参入していました。両社は今でも共通のクリエイティブな顧客に製品を提供するべく共に働いています --- Adobe の Creative Suite 製品の半数は Mac ユーザが購入しています --- が、金銭的な関係はほとんど無くなりました。

私は Adobe の Flash に対する考えをこうして綴ることで、iPhone や iPod、iPad で Flash を使用できないようにしている理由を、顧客や批評家の方により良く理解していただけることを望んでいます。Adobe は私達の決断を主にビジネス上の理由によるもの --- 私達が App Store を守るため --- だと考えているようですが、実際は技術的な問題によるものなのです。Adobe は私達のシステムは閉鎖的(クローズド)で、Flash こそオープンなものだと言っていますが、真実は逆です。これについてご説明しましょう。

まず最初に、「オープン」ということ。

Adobe の Flash 製品は 100% プロプライエタリです。Adobe からしか入手することができず、Adobe だけが将来的な機能拡張や価格設定などの権利を握っています。Adobe の Flash 製品はかなり普及してはいますが、これはオープンであるということを意味してはいません。何故なら、Adobe がそれらを完全にコントロールしており、また Adobe からのみ入手することのできるものだからです。どう定義しても、Flash は閉鎖的なシステムです。

Apple もプロプライエタリな製品は多く保有しています。iPhone や iPod、iPad のオペレーティングシステムはプロプライエタリですが、Web に関連する標準は全てオープンであるべき、という信念を持っています。Apple は Flash ではなく、HTML5 や CSS、JavaScript を採用しました。これらは全てオープンな標準だからです。Apple の全モバイルデバイスには、これらのオープンな標準に対する高性能かつ低電力な実装系が搭載されています。新しい Web の標準である HTML5 は Apple や Google、その他多くの企業によって採用されており、Web 開発者がより高度な画像・文字・アニメーション・トランジションなどを、Flash のようなサードパーティのプラグインに依存することなく実現することを可能にするのです。HTML5 は完全にオープンで、Apple がメンバーとして参加している標準化団体によって管理されています。

Apple は Web 用のオープンな標準を策定する活動もしています。例えば、Apple は小さなオープンソースプロジェクトから始めて、WebKit を開発しました。完全にオープンソースな HTML5 描画エンジンである WebKit は、私達の全製品に採用されている Safari Web ブラウザの心臓部分です。WebKit は広く採用されています。Google が Android のブラウザとして使用しているだけでなく、Palm や Nokia も使用しており、RIM (Blackberry) も将来的に WebKit を使用すると公表しました。Microsoft のものを除けば、ほとんどのスマートフォンが WebKit を使用しています。WebKit の技術をオープンにしたことで、Apple はモバイル Web ブラウザの標準を確立したと言えます。

2 つ目に、「完全な Web」ということ。

Adobe は Apple のモバイルデバイスが「完全な Web」にアクセスできないと繰り返し述べています。Web 上にある動画の 75% が Flash 形式だからだそうです。彼らは言いませんが、これらの動画のほとんどは、より現代的なフォーマットである H.264 で公開されていて、それらは iPhone や iPod、iPad で視聴できます。Web 上の動画の 40% を占めると推定される YouTube は、Apple のモバイルデバイス全てでアプリケーションとしてバンドルされています。特に iPad では、YouTube で動画を探して視聴する、おそらく過去最高の体験を提供しているでしょう。Vimeo、Netflix、Facebook、ABC、CBS、CNN、MSNBC、Fox News、ESPN、NPR、Time、The New York Times、The Wall Street Journal、Sports Illustrated、People、National Geographic、その他たくさんのサイトの動画も同様に観ることができます。iPhone や iPod、iPad のユーザが見逃している動画は、そう多くはないでしょう。

Adobe は、Apple のデバイスでは Flash ゲームで遊ぶことができないとも言っています。これは間違ってはいません。ただ、幸運にも 50,000 以上のゲームやエンターテイメントソフトが App Store にあり、それらの多くは無料です。iPhone や iPod、iPad 向けのゲームやエンターテイメントソフトは、世界中のどんなプラットフォーム向けのものよりも多いでしょう。

3 つ目に、信頼性、セキュリティ、そしてパフォーマンス。

Symantec は先日、Flash を 2009 年の最も悪いセキュリティ記録を持つソフトウェアとして取り上げました。さらに私達は、Flash が Mac をクラッシュさせる理由の No. 1 であることを直接的に知っています。これを改善するべく何年も Adobe と協力していますが、現在に至るまで問題は解決していません。Flash を追加することで、iPhone や iPod、iPad の信頼性やセキュリティを落としたくはありません。

また、Flash はモバイルデバイスでのパフォーマンスがあまり良くありません。私達は Adobe に、どんなモバイルデバイスでもいいから快適に Flash が動いているところを見せてくれと言い続けていますが、未だに見たことがありません。Adobe は 2009 年初頭にスマートフォン向け Flash を出荷すると公表していましたが、しばらくすると 2009 年の後半になり、さらに経つと 2010 年の前半だと言い始めました。そして今では 2010 年の後半だと言っています。いずれは出荷するのでしょうが、いつまでも息を止めて待つことはできません。誰もどのように動作するのか分からないのですから。

4 つ目に、バッテリーの寿命。

動画を再生するモバイルデバイスが長いバッテリー寿命を実現するには、動画をハードウェアでデコードすることが必須です。ソフトウェアでデコードすると、電力を激しく消費します。現代的なモバイルデバイスで使われるチップの多くには、H.264 というデコーダが搭載されています。H.264 は全ての Blu-ray DVD プレーヤで使われている業界標準の技術で、Apple や Google (YouTube)、Vimeo、Netflix など数多くの企業で採用されています。

Flash は最近になって H.264 に対応しましたが、今のところ、ほとんど全ての Flash 採用サイトにある動画は、旧世代のデコーダを必要とします。このデコーダはモバイルチップには実装されていないため、ソフトウェアで実行する必要があります。この違いは致命的です。例えば iPhone では、H.264 の動画であれば最大 10 時間再生できるのに対し、ソフトウェアでデコードされる動画は 5 時間もしないうちにバッテリーが空になってしまいます。

Web サイトが動画を H.264 形式で再エンコードすれば、Flash に頼らなくても動画を配信できます。これらの動画は Apple の Safari や Google の Chrome などのブラウザでプラグインを全く使用せずに再生できるほか、iPhone や iPod、iPad などにも対応できるのです。

5 つ目に、タッチ。

Flash はマウスを使う PC 向けにデザインされており、指を使って操作するタッチスクリーン向けではありません。例えば、多くの Flash 採用サイトで「ロールオーバー」という手法が使われています。これはマウスの矢印が特定の場所の上に来たときにメニューやその他の要素をポップアップする、というものです。Apple の革新的なマルチタッチインタフェースはマウスを使わないので、ロールオーバーという概念が存在しません。Flash 採用サイトのほとんどは、タッチデバイスをサポートするために書き直しが必要になります。開発者が Flash のサイトを書き直すくらいなら、HTML5 や CSS、JavaScript のように、より現代的な技術を使わない理由はないでしょう。

もし iPhone や iPod、iPad 上で Flash が動いたとしても、ほとんどの Flash サイトがタッチデバイスに対応するための書き直しが必要になるという問題は解決しません。

6 つ目、これが最も重要な理由です。

Flash が閉鎖的でプロプライエタリで、大きな技術的な問題を抱え、タッチデバイスをサポートしていないことを除いても、私達が iPhone や iPod、iPad 上で Flash を許可できない重要な理由があります。ここまで Flash を動画再生や Web サイトの動的コンテンツに使用することの欠点について議論してきましたが、Adobe は開発者に対して、私達のモバイルデバイスで動作するアプリケーションの開発に Flash を採用することさえ望んでいるのです。

サードパーティレイヤのソフトウェアがプラットフォームと開発者の間に存在することを野放しにしておけば、最終的に標準未満のアプリケーションが量産され、ひいてはプラットフォームの拡張と進歩を遅らせてしまう。私達はそのことを、辛い経験を通じて知っています。開発者がサードパーティの開発ツールとライブラリに依存したまま成長してしまうと、もしプラットフォームの機能が拡張されたとしても、サードパーティがそれを採用するまで、その新機能の恩恵にあずかることができません(あるいは、その機能自体が採用されないかもしれません)。私達は、開発者が新機能を利用できるかどうか、そしてそれがいつになるのかを、サードパーティの思いのままにしておくことはできません。

これは、サードパーティがクロスプラットフォームの開発ツールを提供している場合、より悪いものになります。サードパーティはそのツールがサポートしている全てのプラットフォームで利用可能になるまで、ある特定のプラットフォームの新機能を採用しないことがあるからです。結果として、開発者は最大公約数的な機能しか利用することができなくなってしまいます。繰り返しますが、競争相手のプラットフォームに搭載されていないことを理由に、私達の革新的な新機能や拡張を開発者が利用できない、というような状況は、到底容認できるものではありません。

Flash はクロスプラットフォームな開発ツールです。Adobe の目的は、開発者が iPhone や iPod、iPad 向けに最高のアプリケーションを作れるようにすることではありません。彼らの目的は、開発者にクロスプラットフォームのアプリケーションを作らせることです。しかも Adobe は、Apple のプラットフォームにおける新機能を取り入れるのが非常に遅いと言えます。例えば、Mac OS X は約 10 年前から販売されているにも関わらず、Adobe が Mac OS X に完全に(Cocoa)対応したのはたった 2 週間前、CS5 を発売したときです。Adobe の Mac OS X への完全対応は、大手のサードパーティ開発者の中では最後でした。

私達のモチベーションは単純です --- 私達は最も先進的で革新的なプラットフォームを提供することで、開発者にその真上に立って、世界で最高のアプリケーションを創造してほしいのです。私達は開発者が、もっと驚きに溢れた、パワフルで楽しい、役に立つアプリケーションを作ることができるように、プラットフォームを継続的に改善してゆきたい。全ての人がこの恩恵を受けることができます --- 私達は最高のアプリケーションに支えられてより多くのデバイスを売り、それによって開発者はさらに多くの視聴者や顧客にリーチできる。そしてユーザは、どんなプラットフォームよりも高品質かつ幅広いアプリケーションを絶えず楽しむことができるのです。

結論。

Flash は PC の時代、言い換えれば PC とマウスのためのものです。Flash は Adobe にとって成功した事業であり、私達もなぜ彼らが PC 以外のデバイスに Flash を広めたいのか理解できます。しかし、モバイルの時代は低電力デバイスとタッチインターフェース、オープンな Web 標準のものであり、Flash はそのどれにおいても力不足です。

Apple のモバイルデバイス向けにコンテンツを提供するメディアが急増していることは、動画の視聴や Web コンテンツの利用に Flash が不要であるということを表しています。そして Apple の App Store にある 200,000 を超えるアプリケーションこそ、多数の開発者にとって、ゲームなどのリッチなグラフィクスを持つアプリケーションを作るために Flash が不要であるということの何よりの証拠だと言えます。

モバイル時代に作られた新しいオープンな標準、例えば HTML5 こそが、モバイルデバイスでの(そして PC でも)勝者となるでしょう。Adobe は過去を捨てゆく Apple を非難することは止めて、未来に向けて素晴らしい HTML5 ツールを開発することに集中するべきです。


スティーブ・ジョブズ
2010 年 4 月