TOKUNAGA Hiroyuki
tkng****@xem*****
2003年 10月 22日 (水) 04:18:18 JST
徳永です。長文シリーズ2回目です。あと2,3回ぐらい続く予定です。 さて、今回はなぜuimがサーバ/クライアント方式を取っていないのかという事 について書きます。 もちろん、サーバ/クライアント方式といいましても、TCP/IP or UnixDomain、シングルユーザorマルチユーザ、ということで、計4種類ぐらいの 形態が考えられ、一括りにするのは無理があります。 そこで、どの形態でどの問題が発生するのか、という事を書いてみます。 問題1 認証 これはTCP/IPを使う場合に発生します。異なるホスト間で認証する場合、ユー ザがパスワードを管理する必要性がでてきますが、めんどくさそうです。 問題2 経路の暗号化 これはTCP/IPを利用し、異なるホスト間で通信する場合の問題点です。もちろ ん自力で暗号化なんてした場合には穴だらけでしょうからSSLなどを使うことに なるでしょうが、SSLだってときどきセキュリティホールが見付かります。 問題3 バッファオーバーフロー これもTCP/IPの場合の問題点です。落ちるぐらいならまだいいですが、権限乗 っ取りなんてされたらどうしようかと思います。 他にも問題があるかも知れませんが、私に思い付くのはこれぐらいです。結局 のところ、TCP/IPのときにセキュリティの事を考えると、様々な問題が出てくる という話ですね。 問題3などは気をつければ回避できる問題かもしれませんが、私はまだ 経験が浅く、その自信がありません。また、CannaやWnnにセキュリティホールが 見付かっているところをみると、経験有るプログラマでもこれらの問題を完全に 回避するのは難しそうです。 UnixDomainを使うのはプロセス間通信のためであり、これには特段語るべきこ ともないように思われます。これに対してTCP/IPを使うのはホスト間通信（を実 現したい）のためであり、上記の様な問題が発生します。 では、TCP/IPを使ってホスト間で通信を行う事によるメリットはないのかとい うと、そういうこともありません。異なるマシン間での辞書の共有が簡単に できるようになるとか。 しかし、私にとって、発生するリスクと労力に見合うほどのメリットではない ですし、大多数の人にとってもそれは同じではないかと推測します。 たぶん、iiimfの人にとってはこのメリットは譲れないところなのではないか と推測しているのですが、推測していても真実はわからないので、近いうちに iiimfのMLにメールを投げて確認しようと思ってます。 それと、現在のuimには、UnixDomainSocketに関連して、ローカルユーザが他 のユーザが現在どのInputMethodを使っているのか、どのようなモードになって いるのかを知られてしまう不具合があります。（入力している内容は漏洩はしま せん。） これは、ソケットに接続する際にソケットのパーミッションと所有ユーザを確 認していないからです。次のリリースまでには改善します。 ちなみに、次のリリースは候補ウィンドウつきでだすつもりにしていたのです が、難しいかもしれません。 徳永拓之
