ruby-dev

In article <43094AA9.1010608@ruby-lang.org>,
  Shugo Maeda <shugo@ruby-lang.org> writes:

> うーん、そうなんでしょうか。
> 私の感覚では、情報漏洩の危険性はかなり大きい(場合によってはデータを
> 壊されるよりも、盗られる方が嫌です)のですが、田中さんのような考え
> の方が多いのならば、考えなおすべきかもしれません。

どういう安全性を要求する人が多いか、というのは重要な点だと思います。そ
して、私は今まで taint 機構を避けてきたこともあり、私と同じように考え
る人が多数であるという自信はありません。ここはいろんな人の意見を聞いて
みたいところです。

また、現在どういう人が多いかというのとは別に、将来的にどういう人が多く
なっていくと幸せか、という点もありますね。

ただ、前田さんの提案で情報漏洩の危険をどう防げるのか、というのはよくわ
かりません。というか、前田さんの提案が防ぐのものがうまくイメージできま
せん。不注意を防ぐ、というのでしょうが、なぜ不注意を防いで安全性を向上
させる効果があるのかを理解できないのです。

> 私の提案の意図としては、ライブラリ作者がtaint機構によって確認するのは、
> ライブラリの安全性ではなく、ライブラリが*本来の意図に反して*外部への
> アクセスを行っていないかどうかです。
> delete_filesを本来の意図通りに動作させるために必要ならば、untaintする
> べきだという考えです。
> delete_filesを呼び出したユーザは、delete_filesが仕様通りにファイルを
> 消してくれることを期待して、delete_filesに渡す引数をuntaintするわけ
> ですから、それで問題ないように思います。

この説明で、前田さんの提案はかなりクリアに理解できたように思います。
結局、引数が taint でないことをもって呼び出し側に動作の許可を与えてい
るとみなすわけですね。

それに対する私の疑問は、それなら $SAFE=1 は何の役にたっているんだろう
か、というところです。

ライブラリが本来意図する動作は行われる (許される) わけですから、すべて
の (ほとんどの) ライブラリに共通して禁止される動作というものはないわけ
です。

そして、本来意図する動作である限りにおいて、データを untaint するわけ
ですが、そこで何に注意することが促されてどういう安全性に役に立つのか、
という部分がよくわかりません。

> その場合には、ユーザはそのライブラリに手を加えないと使えないと
> いうことになる(今回のopen-uriの件のように)と思うのですが、その点
> についてはどう思われますか?

それはライブラリの作者の裁量の範囲だと思います。

仕様をよく理解していなかったり、あるいは間違ってそのメソッドを使ってし
まう危険性を重視するなら、$SAFE=1 では使わせずに、使うときは $SAFE=0
を要求するというのはあり得るスタンスだと思います。

> おそらくPerlをほとんど知らない私は適任ではないのだと思います。
> 実際にPerlのtaint機構を使われている方のご意見をお聞きしたいところです。

えぇ。ぜひ詳しい人の意見が聞きたいです。
-- 
[田中 哲][たなか あきら][Tanaka Akira]

Thread

Prev Next

In This Thread

Prev Next