脳log[20110411] 「HsbtDiary(2011-04-11) rubygems の taint と LOAD_PATH と $SAFE について」

最終更新: 2011-04-16T21:35+0900

♪ [Ruby] 「HsbtDiary(2011-04-11) rubygems の taint と LOAD_PATH と $SAFE について」

前にこうならんかな？って書いたのをもう一度。

require 'hoge'

したときに hoge.rbなり hoge.soなりが taintedな $LOAD_PATH要素に基づいて発見されたときは SecurityError。見つからなければ taintedな要素はスルー。という動作を Rubyに期待したい。今は taintedな $LOAD_PATH要素を無造作に File.expand_pathして SecurityErrorが起こるに任せているんではなかったか。

 @2011-04-16 Ruby 1.9.2p136と 1.8.7p330で挙動が違うのが SecurityErrorへの疑問を増す。

1.9.2では(確かめたわけではないけど)汚染されたパスの展開がセキュリティエラーにつながってるから、汚染されたパスが $LOAD_PATHの末尾にあった場合は $SAFE=1の状況下で require 'cgi'が成功する。require '存在しないファイル'はセキュリティエラー。汚染されたパスを基に展開を試行したかどうかが分かれ目。

1.8.7では $SAFE=1の状況下で汚染された文字列を引数にした File.expand_pathは 1.9.2と違い成功するものの、上のような場合でも require 'cgi'に失敗する。これは requireが内部的に File.expand_pathを呼び出し――これは 1.9.2とは違いセキュリティエラーを起こさないけれど 1.9.2同様汚染された文字列を返す――、その汚染された戻り値を使った require_internal(仮名)が 1.9.2とは違い $SAFE=1のときにセキュリティエラーを起こしてるのだと思う。挙動からの推測。

一貫性が欲しかったね。できれば実用的なものが。特定のディレクトリ(汚染された$LOAD_PATH要素)に特定の .rb, .soファイル(requireされたファイル)があるかないか判った(SecurityError or not)ところでどうだというの。