Kimura Fuyuki
fuyuk****@nigre*****
2004年 2月 16日 (月) 11:14:52 JST
At Sat, 14 Feb 2004 16:23:47 +0900, Kimura Fuyuki <fuyuk****@nigre*****> wrote: > > 添付のテストプログラムを実行してみてください。環境によって結果がAとBに > 分かれます。問題なのはAのほうで、私にはこれはセキュリティやモジュラリ > ティの面で非常にまずいように思われます。 考えてみたらセキュリティのほうはたいしたことにはなりませんでした。問題 なのはモジュラリティのほうです。 Gaucheのようなインタプリタにとってこの問題が重要なのは、パターンAの環 境が存在する現状ではバインディングが作れないからです。 実例を挙げます。 私はいまOSSP uuidのバインディングを作っています。DSOは次のようにリンク されています。 uuid.so -> /usr/local/lib/libuuid.so.1 uuid.soからはlibuuid中の関数uuid_*()を呼びます。単純な構成ですね。使う さいにはuuid.soをdynamic-loadします。 これはたいていのシステムで動くのですが、FreeBSDではコアを吐くことがあ ります。なぜかというと、 1. FreeBSDの探索順序は前メールでいうところのパターンAであり 2. goshはlibcをリンクしており 3. libcにはlibuuidのものとは同名非互換のuuid_create()が含まれている からです。つまり、uuid.soはlibuuidのuuid_create()を呼ぶつもりでいるの に、実際にはlibcのものが使われてしまっているわけです。 これの意味するところは、 「DSOの製作者は親プログラムのリンクする共有ライブラリ中のシンボルをす べて事前に知っておかなければならない」 ということです。 そんなことは不可能だし、たとえできたとしても、実質的に衝突を解決する手 段(上の例でいえばlibuuid中のuuid_create()を呼ばせる手段)がありません。 これはDSOをロードするすべてのプログラムに共通する問題です。 私が調べたところでは、次のようなシステムがパターンAの探索順序になって おり、潜在的に上述の危険にさらされています。(Solaris 9もそうらしい) FreeBSD 5.2 FreeBSD 4.8 NetBSD 1.6.1 Linux 2.4 (Redhat 9.0) どうしてこんな大問題がこれまで放置されてきたのかわかりません。過去に誰 も困らなかったんでしょうか。(MD5_*()なんていかにも危なさそうなんですが) それとも私が何か勘違いしているのか、うまい解決方法があるのかもしれませ ん。どなたか教えてもらえませんか？ -- 木村 冬樹
