オタワLinuxシンポジウム3日目：NFS、USB、AppArmor、LSBの話題
NFSが最悪な理由
Olaf Kirch氏による「NFSが最悪な理由（Why NFS sucks）」は、NFSとそれには及ばないが競合するファイルシステムの多くを取り上げたもので、そのタイトルは今年のOLSの講演タイトルのパターン「～が最悪な理由（Why … sucks）」に従ったものである。
最初に彼はこの発表のテーマは間違いなくNFSであり、ここではNFSがいかにすばらしいファイルシステムなのかを紹介する、と 講演タイトルと同様に大まじめに説明した。
誰もがNFSに不満を抱いている、とKirch氏は語り始めた。そのことを証明するために、NFSが優れていると思う人は手を挙げてください、と彼が出席者に向かって言ったところ、100人以上の出席者のうち3人だけが手を挙げた。SUSE LinuxディストリビューションのBugzillaには、さまざまな問題をまとめて表したバグとして「NFS sucks」というものがしばらくあったが、最近になって削除された、と彼はコメントした。
続いてKirch氏はもう少しまじめな口調でNFSの歴史を説明し始めた。1980年代前半、SunのもとにあったのはRFSという制限のあるネットワークファイルシステムだった。1985年、Sunは、NFSバージョン1の存在を公にすることなく、SunOS 2と共にNFSバージョン2をリリースする。1986年には、カーネギーメロン大学とIBMがAFSを開発。1988年、NFSバージョン2にキャッシュを整合させたSpitely NFSが登場する。その後の6年間は大きな進展がないまま過ぎた。1994年、Spitely NFSにクラッシュリカバリ機能が導入され、同じ年にRick Mackelem氏が4.4BSDと共にNot Quite NFS（NQNFS）をリリースする。1995年には、一般的な問題の除去版としてNFSバージョン3がリリースされる。1997年、SunはHTTPに匹敵するほど大きな扱いでWebNFSをリリースしたが、始めから相手にされなかった。そして2002年にリリースされたのが、「インターネットファイルシステム」と銘打ったNFSバージョン4だった。
引き続き、Kirch氏はNFSバージョン2の基本的な点について説明を行った。NFSバージョン2はステートレスプロトコルである。これにより、クラッシュしてリブートまたは再起動した後も、サーバ、クライアントとも何事もなかったかのように処理を継続することが可能だ。NFSサーバがクラッシュした場合、クライアントはNFSサーバが再び動作するまで待ち続けるだけでよく、その後は元の状態で処理を継続できる。これがステートフルプロトコルだと、すべてのクライアントについて状態の記録および追跡をサーバが行う必要がある。ステートレスプロトコルはスケーラビリティの点で優れているのだ。
NFSは、ほとんどどんなファイルシステムでもネットワークファイルシステムとしてエクスポートできる。これはNFSの大きな強みであり、特定のファイルシステムに固有のものでもない。
ファイルには、その存続期間全体にわたって有効なファイルハンドルが必要になる、とKirch氏は説明する。このやり方はinodeテーブルではうまく機能するが、新しいファイルシステムはもっと複雑である。ディレクトリは、その親ディレクトリ（..）のエントリを使って一連のエントリを再構築することができる。ファイルはinodeおよびディレクトリへのポインタになっている。なお、NFSの場合は、これらの識別子が変わる可能性がある。
NFSは2049番ポートの監視を行う。NFSでは、ディレクトリマウント用のファイルハンドルの取得にはmountdへの通知が、接続するポートの取得にはportmapへの通知がそれぞれ必要であり、ファイルのロック、ステートレス状態でのエラー回復、クラッシュ後のロックの回復にもそれぞれ別のプロトコルへの通知が必要になる。新しい機能ごとに別のプロトコルを必要とするバージョン3以前のNFSの考え方に対して、Kirch氏は憤りを露にしていた。ただし、NFSバージョン4では大部分が改善されているという。
Kirch氏によると、NFSバージョン2の評判が悪いのは、実装の詳細が意味のある仕様ではなくて主として古くからの伝統を受け継いだものになっているためだという。彼は、異なる実装の普及が原因となってクライアント／サーバの混乱につながる恐れのある性質の問題に言及している。
開いているファイルのリネームや削除を行っても、そのファイルへの継続的書き込みを許すべきである。NFSバージョン2および3では、ファイルの削除またはリネームが興味深い結果をもたらすことがある、とKirch氏は説明する。NFSバージョン4では、削除されたファイルをドットファイル（.nfs.xxxxxx）に変更するという「思慮の足らないリネーム」により、この問題が解決されている。ただし、このドットファイルも削除可能である。それ以上開かれることがない場合に限り、ドットファイルは削除される。
NFSバージョン2および3では、1つのファイルへの同時アクセスを正しく処理できない、とKirch氏は警告している。その結果が一意に定まらない可能性があるのだ。NFSバージョン4にもこの問題はあるが、厄介な事態になる恐れがあることをエラーメッセージで警告してくれる。
NFSに固有のもう1つの問題はセキュリティが不十分な点である。クライアントマシンがNFSサーバ上のファイルにアクセスしようとしているユーザのユーザIDおよびグループIDをNFSサーバに通知すると、NFSサーバは、クライアントを完全に信用してこの情報を何の疑いも持たずに受け入れてしまう。長い間、数々の対処方法の提案および実装がされてきたが、実際に採用されたものはない。
NFSには、ネットワークを飽和させてしまうという困った傾向もある。バージョン3以前のNFSのプロトコルは、完全にユーザデータグラムプロトコル（UDP）ベースだった。UDPは、極度なビジー状態になるとネットワークがダウンする恐れのある、損失の多いプロトコルである。結論として何らかの輻輳回避の機能が必要だ、とKirch氏は述べている。UDPには、より洗練された再送信機能が必要である。その解決策がTCPであり、現在、NFSバージョン4ではこれらを排他的に用いている。TCPは、パケットを確実に送信先に届け、パケット喪失時にのみ再送信を行う、ステートフルなネットワークプロトコルである。
Kirch氏は、NFSに代わるさまざまなファイルシステムが存在することを述べ、自由に選択できるようにそれらをまとめていた。数多くの代替ファイルシステムとその簡単な説明の後、それぞれの利点と欠点を記した詳細な一覧が示された。
- AFSの存続をはかる手段として、IBMはメンテナンスの継続ではなくオープンソース化の道を選んだ
- DFSはOpen Groupが生み出したものだが、消滅しつつあるか完全に消滅したかのどちらかだ
- CIFSは意外にも健全なネットワークファイルシステムである
- Intermezzoはうまく設計されていたが、姿を消してしまった
- Codaを開発したPeter Braams氏は、その後、別のプロジェクトへの移管を行ったが、これも消滅したに等しい状態にある
- Clusterファイルシステムは、多くの場合、NFS上またはCIFS上のどちらかに存在する
- pNFSと呼ばれる、拡張機能付きNFSは、ファイルとメタデータを別々のサーバ上に保存する
こうした一覧を示したKirch氏は、そのうちのいくつかについてより詳しい説明を加えた。
AFSを「安売り中のアンティーク（Antiques For Sale）」と呼ぶKirch氏によると、このファイルシステムはメンテナンス状態にあるという。AFSはセキュリティ機能をKerberos 4に頼っている。コードそのものは、複数のプラットフォーム間での移植性を確保するために#ifdefステートメントだらけで、読みづらいものだ。また、相互運用性が低く、64ビットのプラットフォームでは機能しない。
Kirch氏が「相互運用不能なファイルシステム（Cannot Interoperate File System）」と揶揄するCIFSは、ステートフルで、コネクションベースのネットワークファイルシステムである。彼はこのプロトコルをジャングルと表現し、とにかく「ひどい状態」にあるとしか言えない、と語った。CIFSの最大の問題は、Microsoftによって管理されていることであり、それが採用の大きな障害になっている、と彼は説明している。ユーザが知りたがっているのは、それでも存続するのか、という点だと彼は補足した。
「これで十分に満足できるのか（Now Fully Satisfactory?）」と自らが表現したNFSバージョン4について、Kirch氏は次のように述べている。NFSバージョン4は、多くの点が修正されたインターネット指向のファイルシステムである。Windowsとの相互運用性を備え、ファイアウォールとの相性がよい単一のポート（2049番）を用いているほか、別のポートを開いてしまうというコールバック処理のコードにあった欠陥もバージョン4.1では修正されている。NFSバージョン4はすっかりTCPに染まり、今やUDPは過去のものになってしまっている。
USBデバイスのリバースエンジニアリングに関する基本事項
FOSSコンサルタントのEric Preston氏によるチュートリアル・セッション「USBドライバのリバースエンジニアリングによる互換性の確保」にも出席した。
冒頭に「このチュートリアルは教育目的に限った内容」だという、よく耳にする断りがあった。
このチュートリアルが行われることになった背景はいたってシンプルで、USBデバイスに対するベンダのサポートが不十分なことが多い、というものだ。ベンダはLinuxにあまり関心がない。彼らの言い分は、誰もLinuxを使わない、というものから、USB-IDはUSBを重視する者の知的財産権だというものまで多岐にわたるが、いずれにしてもベンダはLinuxに目を向けていない。
では我々は何をすべきか、とPreston氏は問いかける。デバイスのベンダや広くコミュニティからのサポートを待つこともできるし、自分たちの手でサポートすることもできる。
したがって、我々の使命は自分たちでドライバを書くために既存のドライバの働きを理解することだ、とPreston氏は述べている。その目的は、優れたハードウェアをサポートし、ユーザ空間のドライバ作成により多くの人々を巻き込んで、経験の乏しい開発者のために障壁を取り除くことにある。つまり、ドライバ開発のつまらなさを軽減して楽しいものにすることだ。
USBデバイスのリバースエンジニアリングに必要になるのは、基本的にusbsnoopyとWindowsだ、とPreston氏は説明する。大半のドライバが揃っているWindowsとusbsnoopyを使うと、USBデバイスとデバイスドライバとのパケットのやりとりをWindowsで確認できる。また、usbsnoopyは各機能の解読を可能にするログを作成してくれる。
何がどうなっているのかを理解するために、WindowsでUSBデバイスに対する簡単なタスクを実行し、そのやりとりを監視してログを取ることができる。これでデバイスのUSB仕様を調査してログを手動で解読できるようになり、何カ月か取り組みを続けると最終的には、何が起こっているのかをある程度突き止めることができるはずである。
VMWareやその他の仮想化プログラムを利用すれば、こうした調査の過程で痛ましいほどに頻発するリブートを回避できるほか、Etherealアナライザと呼ばれるEtherealインタフェースによってUSBデバイスのトラフィックを監視するLinuxネットワークアナライザEtherealと、usbmonを呼ばれるLinuxプログラムとを組み合わせて用いるものなど、usbsnoopyに代わるツールを使うこともできる。Preston氏はこうした代替ツールを開発中だが、そのコードは非常に煩雑で、まだ共有できる状態にはなっていない、と述べている。
USBドライバ自体は、libusbを使えば完全にユーザ空間に作成できる。また、libusbの登場により、もはやUSBデバイスを動作させるためにカーネルドライバを書く必要はなくなっている。このチュートリアルでは、実際にドライバを作成することはなかったものの、Preston氏は会場の定員を上回る数の出席者にその指針を示したのだった。
AppArmor対SELinux
3日目の晩の興味深いBOF（Birds Of a Feather）セッションの中に、IBMのDoc Shankar氏による「Linuxセキュリティの現状」というセッションがあった。
Shankar氏は、主としてSELinuxに注力するセキュリティプロジェクトの最新情報を簡単に紹介するために、数名のセキュリティの専門家を招いていた。ただし、SELinuxの奥の深さは完全に私の理解を超えていた。ただ、著しく私の注意を引いた発表が1つあった。
それはNovellのCrispin Cowan氏による発表で、同社が最近Immunix社を買収し、そのAppArmorという、SELinuxに匹敵すると見られるLinuxセキュリティプログラムを獲得したことが述べられた。
AppArmorのシンプルさとロジックは、なぜそれまで話題にならなかったのかと不思議に思うくらいすばらしいものだった。簡単に言うと、AppArmorはサービスおよびアプリケーションへのアクセスを、特定のルート権限などの権限と、AppArmorの役割を果たすために必要なファイルだけに制限するセキュリティツールである。また、保護対象プログラムによるタスク実行の監視によって明示的に指示しなくてもそれらが何かを学習でき、それぞれの動作をログに出力することができる。Cowan氏は簡単なデモを行って、どうすればApacheをわずか2分でAppArmorに結合できるかを示した。また、サンプルWebページのルートホールの攻撃に必要なリソースの利用を許さないことによって、セキュリティ上の弱点を回避していた。
果たして、この対策を打ち破る方法があるだろうか。
Linux Standard Baseの最新情報
3日目に出席した最後のセッションは、毎年恒例のLinux Standard Baseに関する最新報告で、Mats Wichmann氏によるBOFセッションの形で進められた。
Wichmann氏によると、昨年のOLS以降、Linux Standard Baseバージョン3.1が2回に分けてリリースされたという。まずLinux Standard Base（LSB）のコア部分が2005年の11月に、続いてモジュール群が2006年4月にリリースされた。2つに分けたのは、国際標準化機構（ISO）が定めるISO仕様の最終期限に間に合わせるためだった。
ISOに関与した結果として、現在、LSBには2つの流れが存在する。1つはLSBプロジェクト自身が比較的頻繁に更新を行うバージョン、もう1つがISO向けの仕様である。これら2つの仕様は本質的には同じものだ。
ISO仕様は、主として、テクノロジに対する請け負い入札の公告時に、行政機関がISO準拠の規格として要件に指定できるようにするために存在する。このLSB仕様は、ISO標準23－660として定められている。
LSBのドキュメントは、Free Documentation Licenseとして公開されているが、ISO側でも同機構の方針の下で公式な標準規格として保持できるように、事実上はデュアルライセンスされたドキュメントになっている。
ISO版のLSB標準を最新の状態に保つのはどれくらい困難か、と質問されたWichmann氏は、確かにその点は気になっている、と答えた。たとえLSBプロジェクト自体に進展があっても、ISO仕様の詳細はいつでも変更できるわけではない。ISO仕様は、不定期に正誤表を提出することで最新の状態を維持できるが、ISO仕様の更新サイクルは約1年半である。その結果、必然的にISO仕様はLSB仕様に遅れを取ることになるのだ。
続いて、誰がLSBの認証を行うのか、という質問が出た。それで見返りが得られるなら、LSB準拠のディストリビューションまたはソフトウェアパッケージの認証に経済的関心を持つどの企業でも行える、とWichmann氏は答えた。建前上は誰がどんなソフトウェアの認証を行っても構わないため、たとえ実際の認証プロセスを経験したことがなくても、企業がソフトウェアを規格に準拠させることができない理由はどこにもない、と彼は述べている。
標準規格への適合性の検証方法と、その検証にかかる時間についても質問があった。適合性の検証が自主的に行われていることをWichmann氏は認めた。試験所で実施すると高額な費用がかかるが、ツールをダウンロードして適合性の検証対象であるソフトウェアに対して実行するのは誰でも行える。検証テストは、エラーが出なければ1日で十分に完了できる。もちろん、エラーが発生すればさらに時間がかかる。なお、認証を受けるには、検証テストのログを提出する必要がある。
このセッションの途中、LSBの役割は、程度の差こそあれ、受動的なものだと述べられていた。LSBは、世間一般で標準になっていない標準規格を求めているわけではない。たとえ標準規格として採用されているものよりも優れた規格が存在する場合でも、LSBが求めるのはその押しつけではなく、文書化である。
4日目に向けて
OLSの最終日には、Greg Kroah-Hartman氏による基調講演などが予定されており、刺激的な1日になることは間違いない。ぜひご期待いただきたい。
NewsForge.com 原文
