すべてはXXであり、この視線は本質主義と全体主義の信奉者の叫びでもあります！
引用ツリーモデルについて
ツリーモデルとエブリシング・ファイルは、同じような経験をするという点を除けば、直接の関係はありません。
最近、妻が買ってきた『視覚の華麗なる美』という本を読みました。古代、人々は樹木に魅了され、やがて分類を含む組織構造も樹木となり、後の章を読むと、樹木モデルがすべての本質ではなく、紀元前1万年頃のメソポタミアの三日月地帯で人為的に作られたもの、つまり農業革命が樹木モデルの発想につながったことに気づきました。
ツリーモデルは非常に整然としていて、どの2つのノード間でも一方向の接続性があり、どのノードもトレースすることができ、トレースされることができ、すべてが完璧に見えます。世界のすべてを包含することさえできます。分類学を例にとると、古代ギリシャの哲学者ポルフィリーのツリーが典型的な例で、彼はあらゆるものの属性をあらかじめ定義し、「その属性を持つ」か「持たない」かで物事を分類し、最終的にあらゆるものがツリー上の自分の居場所として葉を見つけることができるのです。木の葉という居場所
ツリーモデルのもとですべてが見事に機能したとき、より本質的な考え方は相互関連性であることがわかり、リンクがすべてとなったとき、ツリーモデルはもはや当てはまらなくなりました。今日、私たちは、社交界、都市、株式、気象、そして脳そのものなど、あらゆるところに存在する複雑なネットワークの時代にいます。しかし、だからといって、「すべては木である」と提唱した古代の人々を否定するものではありません。 彼らのモデルがシンプルであったからこそ、人類文明は生まれ、発展したのであり、今日のカオスへの混乱は、やがてカオスが秩序のカオスであることを発見することにつながるのです。
障害物やボトルネックにぶつかると、物事は横道にそれて、つまり複雑さやカオスに向かっていくのですが、複雑さやカオスが目的ではなく、むしろ前進を続け、上へ上へと進むための穴を見つけようとしているのです。植物が生き生きと成長するように。すべてはドキュメントである」というのがUNIXの信条のひとつですが、今日、それにはいくつかの課題があります。
すべてがドキュメントであることの反例
procfs、プロセス・ファイル・システム。これはUNIXシステム上のプロセス状態と関連データを表示するためのインメモリファイルシステムです。長い歴史があり、おそらく最初から「すべてはファイルである」という事実上の伝道者でした。
すべてはファイルであり、その本来の意味はこうです。つまり、ファイル操作は統一されたシンプルなインターフェイスを持っています。紀元前1万年のコンピュータの時代には、人々は読み取り、書き込み、すべての操作を制御するために削減することができますので、読み取り、書き込み、ioctlは、ファイル操作の最古のセットになりました。すべての操作をファイル操作にまとめようとすると、メカニズムやポリシーを抽象化する一連のマッピングを作成する必要があります。 このマッピングは1対多で、単一の操作プリミティブがメカニズムを表し、その操作の複数の異なる実装がポリシーとして表され、最終的にVFSが誕生しました！
VFSを使えば、何でもファイルシステムとして実装できて便利でした。今日に至るまでLinuxはこの種のことを続けており、UNIXのように止める気配はありませんが、もちろんそれは後付けです。このようなことが十分に行われ、後にIPネットワークが直面したようにセキュリティ要件が大きくなると、ジェネリックに基づく単純なACLでは、すべてのセキュリティ制御ルールをマッピングするのに十分ではなくなります。問題の核心は、VFSがファイルシステムの種類と数を制御できないことにつながるのに対し、UNIXのファイルACLは決定論的であるため、VFSのマッピングと並行して、ポリシーにマッピングする別のメカニズム、つまりVACLが必要になるということです。
しかし、ACLの粒度が粗すぎるため、VACLは存在せず、そのセマンティクスはファイル所有者に対してのみで、「できるかできないか」しか言えず、「できる場合に何をしなければならないか」までは言えないのですが、その後、ポルフィリー木分類に似たものが登場します。しかしその後、ポルフィリー木分類のような「ケイパビリティ」と呼ばれるものが登場しました。これは、考えられるすべての操作を2進数のビットで表し、あるエンティティがその操作を行う許可を持っていれば1、そうでなければ0というものです。これによってUNIXのケイパビリティモデル、POSIX Capが生まれ、すべてが完璧に思えました。procfsも同様に、Capを使ったセキュリティ管理には不向きでした！
procfsにはすべてがあります。このファイルシステムの内容は自動的に生成され、各プロセスはその中にディレクトリを持ち、そのディレクトリの下にそのプロセスの属性が存在します。これらのファイルに対する操作のためのCapは誰が定義するのでしょうか？もしそれがシステムであるなら、プロセスを生成するときに、システムはどのように定義するのか知っているのでしょうか？procfsの本来の目的は単純で、2つのカテゴリがあります：
- エクスポートシステム情報
- エクスポートプロセス情報
いずれにせよ、デバッグ機能を強化するためのものです。いずれにせよ、procfsを使ってUNIXの原則に反することをしようとすべきではありません。最初の問題は、procfsによってエクスポートされる情報にプロセスのアドレス空間が含まれていることです。 プロセスのアドレス空間を分離することはUNIXの、いや、すべてのオペレーティングシステムの基本原則であり、それがprocfsに表示されるときはいつでも、読んだり、書いたり、mmapしたり...することができます。BSDを含む多くのUNIXは、このためにうまくいかなくなったので、後のバージョンは単にprocfsを削除しました。第二の問題は、カーネル空間が情報のフォーマットを扱うべきかどうかという問題にあります。バイナリデータを直接エクスポートすることは procfs の意図に反しています。バグや問題を修正せず、単にprocfsを手放す理由は、Linuxの折衷主義とは対照的なUNIXの設計の純粋主義の反映です。
#p#
プロックスは残るべきか、それとも去るべきか、多くの議論があります：
- プロセス属性の一部であるアドレス空間がエクスポートできないのに、なぜ残りの90％以上を維持するのでしょうか？
- procfsは維持されるべきです。sysctlがすべてのUNIXシステムの標準ツールセットの一部ではないという事実によって引き起こされる相互運用性の問題を考慮すると、統一インターフェースにはprocfsを維持することが推奨されます。
いずれにせよ、これはUNIXの哲学的な問題をめぐる議論です。しかし、linuxはすべてを置き去りにして、独自のprocfsを実装しています。
Linuxの妥協
Linuxは、procfsを放棄する代わりに、そのクリティカルな問題にパッチを当て、その他の非クリティカルな問題については、Linuxコミュニティは気にしませんでした。procfsのVFSオペレーションセットの定義について、Linuxは以下の定義を使っています：
#define mem_write NULL
#ifndef mem_write
//怖いノート！
/* This is a security hazard */
static ssize_t mem_write(struct file * file, const char * buf,
...
#endif
static struct file_operations proc_mem_operations = {
.llseek = mem_lseek,
//read操作上の制限がたくさんある、他のプロセスのアドレス空間へのアクセスを許可しない！
.read = mem_read,
//NULL書き込み操作を定義する
.write = mem_write,
.open = mem_open,
//いいえmmapの実装
};
これにより、セキュリティ上の問題を回避することができます！
Linuxはすべてがファイルであるという道をどんどん進んでいますし、これからも進んでいくでしょう。最近は、procfs、sysfs、devfs、debugfs、cpuset、cgroup、sockfsなどなど、型破りなFSをたくさん見かけるようになりました。...Linuxは、procfsを含むすべての型破りなファイルシステムを慎重に管理し、何が読めるか、何が書けるか、何が厳しく禁止されているかなど、すべて慎重に検討した後、私はLinuxだけがこのようなオープンな開発プラットフォームは、あえてそうしていると思います、抜け穴があれば、すぐに見つけることができ、その後、修正するために最速のスピード！
