[#26430] compile error of missing/*.c — nobuyoshi nakada <nobuyoshi.nakada@...>
なかだです。
まつもと ゆきひろです
こんにちは、なかむら(う)です。
こんにちは、なかむら(う)です。
[#26443] cvs [diff aborted]: cannot open file .cvsignore for comparing: No such file or directory — Tanaka Akira <akr@...17n.org>
最近、cvs diff に -k option を付けると、エラーになる (ことがある) ので
[#26463] String#each_byte and String#each_char — "NARUSE, Yui" <naruse@...>
成瀬です。
[#26468] $SAFE=1 の open-uri で redirect 時にエラー — Kazuhiko <kazuhiko@...>
かずひこです。
In article <m3zmsylimn.wl%kazuhiko@fdiary.net>,
まつもと ゆきひろです
In article <1120754832.716261.15867.nullmailer@x31.priv.netlab.jp>,
まつもと ゆきひろです
In article <1120762886.189058.18880.nullmailer@x31.priv.netlab.jp>,
まつもと ゆきひろです
In article <1120810939.815280.27104.nullmailer@x31.priv.netlab.jp>,
まつもと ゆきひろです
前田です。
まつもと ゆきひろです
In article <42CF1918.5000603@ruby-lang.org>,
前田です。
In article <42D7C230.7030509@ruby-lang.org>,
In article <42DDBA82.7030307@ruby-lang.org>,
[#26493] can't handle \c\ — KIMURA Koichi <kbk@...>
木村です。
卜部でございます。
木村です。
[#26508] rmdir(2) on windows doesn't set ENOTDIR — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
山本です。
まつもと ゆきひろです
山本です。
山本です。
[#26530] removing static variables in parse.y — nobuyoshi nakada <nobuyoshi.nakada@...>
なかだです。
[#26566] cannot compile io.c on windows — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
山本です。
[#26574] SystemCallError.new("abc") => #<SystemCallError: unknown error - ab> — Tanaka Akira <akr@...17n.org>
次のように、メッセージの最後が切れます。
まつもと ゆきひろです
なかだです。
山本です。
まつもと ゆきひろです
なかだです。
山本です。
なかだです。
山本です。
なかだです。
なかだです。
まつもと ゆきひろです
山本です。
この変更があってからだと思うのですが、リンカが以下のように警告を発するよ
卜部です。自己レス
At Sat, 30 Jul 2005 02:32:38 +0900,
[#26594] test_s_open_lock failed on Solaris — Tanaka Akira <akr@...17n.org>
次のように、Solaris で test_s_open_lock が失敗します。
[#26618] Re: [ruby-cvs] ruby/ext/socket, ruby, ruby: * ext/socket/socket.c (ruby_connect): break immediately if a — Tanaka Akira <akr@...17n.org>
In article <20050728015209.0F30DC6734@lithium.ruby-lang.org>,
In article <1122518643.429222.1408.nullmailer@x31.priv.netlab.jp>,
[#26623] Ruby2.0BlockParameterNotation — SASADA Koichi <ko1@...>
ささだです。
まつもと ゆきひろです
[#26628] show information of '--enable-pthread' — Hidetoshi NAGAI <nagai@...>
永井@知能.九工大です.
まつもと ゆきひろです
永井@知能.九工大です.
わたなべです。
こんにちは、なかむら(う)です。
永井@知能.九工大です.
永井@知能.九工大です.
In message <20050731.094203.74726476.nagai@ai.kyutech.ac.jp>
永井@知能.九工大です.
こんにちは、なかむら(う)です。
永井@知能.九工大です.
まつもと ゆきひろです
永井@知能.九工大です.
まつもと ゆきひろです
永井@知能.九工大です.
なかだです。
永井@知能.九工大です.
永井@知能.九工大です.
こんにちは、なかむら(う)です。
永井@知能.九工大です.
こんにちは、なかむら(う)です。
こんにちは、なかむら(う)です。
[#26639] SEGV at zsuper with anonymous rest args. — nobu@...
なかだです。
まつもと ゆきひろです
山本です。
なかだです。
[ruby-dev:26558] Re: $SAFE=1 の open-uri で redirect 時にエラー
In article <42D7C230.7030509@ruby-lang.org>,
Shugo Maeda <shugo@ruby-lang.org> writes:
> それでは、逆に安全だと判断したケース(たとえばschemeがhttpでGET/HEADのみ)
> だけuntaintするようにすればよいのではないでしょうか。
なぜ「schemeがhttpでGET/HEADのみ」というのを安全と判断するのでしょう?
前田さんが [ruby-dev:26484] で示唆したように、その場合でも情報漏洩の危
険性はありますよね。
安全性の基準はなんでしょう?
> # open-uriには無限ループの検出機構はないんですっけ。
> それも心配ということであれば、$SAFE >= 1ではredirect先のURLが取り出せる
> ような例外を発生させる、という仕様でもよいと思います。
心配すべきかどうかがよくわからないのです。
たとえば、ユーザは情報漏洩の可能性を自分で防がなければならないと考える
人が多いでしょうか、それともライブラリが防いでくれると考える人が多いで
しょうか?
それによって心配したほうがいいかどうかが変化すると思います。
> taint機構は、($SAFE == 1では)完全な安全性を提供するものではなく、
> なるべくうっかりミスを減らすためのものだと思います。
安全性っていろいろあると思うんですが、taint機構が想定する安全性って何
でしょう?
たとえば、情報漏洩を防ぐことはその安全性に含まれるでしょうか?
> ライブラリの仕様(この場合はredirectされる条件)が明らかになっている
> のであれば、それをどう使うかは基本的にアプリケーションプログラマの
> 責任ではないでしょうか。
> もちろん、File.unlinkのように危険性があきらかであれば排除するのが
> 望ましいと思いますが、ライブラリ側ですべての危険性を考慮するのは
> 難しいのではないかと思います。
私の疑問は、ライブラリの仕様としてどういう安全性を提供すべきだろうか、
というところです。open-uri が提供する安全性は、taint 機構が提供する安
全性とは独立に定義することも出来ますが、その間にギャップがあると、
* taint 機構の安全性から open-uri の安全性を類推したユーザが危険な使い
かたをしてしまう
* 提供する安全性が異なるライブラリを組み合わせた場合に、ユーザがギャッ
プを埋めるために書かなければならないコードが増え、失敗してセキュリティ
問題が発生する可能性も増える
* ギャップが大きい程、私が書かなければならないコード・ドキュメントが増
え、私の注意深さもより必要になり、私が失敗してセキュリティ問題が発生
する可能性も増える
というような問題が生じるように思います。
taint 機構が提供する安全性と open-uri が提供する安全性が一致していれば
そういう問題は起きないわけです。
というわけでまずは taint 機構が提供する安全性を理解したいのですが、そ
の安全性って何なんでしょう?
>> 根本的なところで、taint 機構が対象としている危険性とはなにか、というと
>> ころがよくわかりません。
>>
>> perl が参考にならないか、と思って perlsec を読んでみたりもしたのですが、
>> あっちは read mode の open が許されていたり、想定されている危険性が違っ
>> ている気がしました。
たとえば、perlsec の最初のほうに
You may not use data derived from outside your program to affect some-
thing else outside your program--at least, not by accident.
という記述で始まるパラグラフがあります。これは perl の taint 機構が何
を禁止するかという方針を (未定義な安全性とか危険性という言葉を使わずに)
表現しています。たとえば、read mode な open はファイル名が taint であっ
ても許されるというのはこの説明から理解できます。また、perl は秘密情報
を読み込むことは禁止しておらず、taint 機構が有効だからといって情報漏洩
はとくに防がれないということもわかります。
それに対して、Ruby の taint 機構には (少なくとも私は) そのような明示的
な説明を見た覚えがありません。マニュアルには
ひとつ目は、信用できない入力をもとに作られたオブジェクトを「汚染されている」と
みなし、「危険な操作」の引数として使えないようにすることです。悪意あるデータに
よって、プログラムが意図しない動作をする事を防ぐことを目的としています。
という記述がありますが、ここでの「危険な操作」という言葉はとくに定義さ
れていません。もちろんその後に危険な操作のリストはあげられていますが、
なぜ、それらの操作を危険とみなすのかの説明はなく、結局どういう操作を危
険とみなすのかという方針がわかりません。
しかたがないので、危険な操作のリストから ruby の方針を推測すると、read
mode の open とか 1.9 で ENV[] が禁止されているところからみて、ruby で
は秘密情報を内部に取り込むことによる情報漏洩の可能性も危険性として考え
ているのではないだろうかと感じられます。
そうすると、open-uri で redirect を行うというのは、秘密情報を取り込ん
でしまう可能性を生むわけですから、禁止するのは妥当かもしれないとも思う
わけです。
でも、結局のところ、ruby の taint 機構で危険だとされる操作がなぜ危険と
みなされるかという方針の説明がないため、確信に至ることができません。
そういう taint 機構の安全性の方針ってどこかに説明されていないんですか
ね?
--
[田中 哲][たなか あきら][Tanaka Akira]