[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[debian-users:18574] Re: gnome-same-gnome とかの日本語表示
永井＠シリウスです。
後藤さんの先のご説明で、なんとなく私の頭の中のもやもやがすっ
きりしてきましたような気がします。
>>>>>> GOTO Masanori <gotom@debian.or.jp> wrote:
gotom> 「system の defaut path である (例えば) /usr/lib/gconv 以外は
gotom> insecure であるため検索しない」
そこが私が判断しかねていたところです。「/usr/lib/gconv は
libc にとってシステムデフォルトパスか否か」と。
本来、libc にとっては /usr/lib/gconv はシステムデフォルトで
あるので、SUID/GUID に関わらず /usr/lib/gconv は検索されなけれ
ばならない、ということであれば納得がいきます。だからその中にあ
る so が暗黙の内に検索されないのはまずい、と。
gotom> secure 云々の以前にデフォルトパスにある /usr/lib/gconv の中の
gotom> libJIS.so が使えなければ、元も子もないのでは?
上記のとおり、私もそのとおりだと思っておりました。
gotom> setuid されたプログラムが LD_LIBRARY_PATH に指定されたパスにある
gotom> libJIS.so を dynamic loading するとき、もしこれがユーザーが悪意
gotom> をもって作った .so だとすると system 的に insecure なので、
gotom> これは回避しなければなりませんが。
はい、これに関しては理解しております。
gotom> なお、EUC-JP の .so が正しく dynamic loading できている
gotom> (strace の結果による) ことから、またそのとき /usr/lib/gconv
gotom> を正しく expand していることから、libJIS.so の問題であること
gotom> は間違いありません。
この事実を見落としておりました。あとになってBTSの内容をみて、
「ああ、EUC-JP.soは読めてたのか」と気が付きました。で、いまさ
ら自分の見間違いに気が付いたのですが iconvdata/Makefile では、
LDFLAGS-libJIS.so = -Wl,-soname,$(@F)
となっているところが問題だったんですね。ここに本来、-rpath
$$ORIGIN が入るべきだ、と。先に
LDFLAGS-EUC-JP.so = -Wl,-rpath,'$$ORIGIN'
$(objpfx)EUC-JP.so: $(objpfx)libJIS.so
って書いてあったのを読み違えて早とちりしてました。この部分は
libJIS.so のローディングパスとは何の関係もない記述ですね。情け
ない(;_;
とすると、現在ほかの so が /etc/ld.so.conf に指定せずに
/usr/lib/gconv から読み出す仕組みになっていること考えると、正
しい解はこちら、ということになるわけですか。たしかに ld.so が
rpath の言うことを聞かないってわけはないですもんね（この部分に
対する解釈も変な風に誤解してました）。
gotom> # P5-90 のマシンで glibc をコンパイルすると
gotom> # 猛烈に時間がかかるので、まだ結果が出てません :-)
私も一度コンパイルしようとしたんですが、むやみに素人がこの領
域に手を出すとシステムが復旧できなくなっちゃうんで踏み止まって
いました（configure に linuxthreads や crypt の add-on がない
といっておこられたので、その先はこわくてやってない）。
でも libc を自分でコンパイルして試せるようになっていると何か
と便利ではと思ってもいます。この方面の debian 的な手法という部
分も含めて、なにか詳しい解説ってどこかにありますでしょうか？
もちろん、まだ付属ドキュメントをちゃんと読んでないので、まずは
そちらでしょうけど。
---
Toyohiko Nagai <nagai@xxxxxxxxxxxx>
PGP Key fingerprint : F2 40 A5 42 F6 49 65 FF 09 B0 B3 77 5F 2A F6 F7