The behavior of NetBSD's setenv(3)

NetBSD's setenv(3) doesn't raises EINVAL even if its name argument contains `='.
1
成瀬 @nalsh

NetBSDのsetenv(3)ってnameに=を含む引数を許すのか

2010-05-19 16:53:24
tnozaki @tnozaki

@nalsh setenv("FOO=bar", "buzz") の場合、environは FOO=buzz になったはず、つまり '=' 以降は無視されるちう感じだったかと

2010-05-19 17:20:16
成瀬 @nalsh

@tnozaki なーるほど、じゃあそのようにテスト側を直しときます。ありがとうございます

2010-05-19 17:40:59
Takahiro Kambe @_taca_

@nalsh 昨日、気になって簡単なCのコードを書いてました。#NetBSD: setenv("foo1=bar1", "baz1") => foo1=baz1, #FreeBSD: EINVAL

2010-05-19 18:27:42
tnozaki @tnozaki

@_taca_ EINVALになるのはPOSIX.1-2001からですが、結局こないだのFreeBSD setenv(3) exploit と同じ問題を孕んでるんですよねー

2010-05-19 18:45:04
tnozaki @tnozaki

setenv(3) の name に '=' を含む場合 EINVAL を返すというPOSIX.1-2001の仕様をまじめに実装すると

2010-05-19 18:52:02
tnozaki @tnozaki

setenv("FOO=", "bar", 1) でFOOの値がbarで上書きされなくなるので、上書きされることを100%仮定して戻り値をチェックしてないコードがlink loaderとかにあったりすると

2010-05-19 18:53:25
tnozaki @tnozaki

こないだのFreeBSD unsetenv(3) exploitと同じ結果になるかもしれないわけでして

2010-05-19 18:53:55
tnozaki @tnozaki

ちなみに OpenBSDでは一度は仕様通りに実装したものの、コメント化してNetBSDと同じくエラーにしないようにしてたり

2010-05-19 18:55:37
Takahiro Kambe @_taca_

@tnozaki "foo1=bar1"なんて名前の環境変数をセットしようとするのはまずいですが、エラーならないのはまだしも、既存の"foo1"の値が意図せず変えられてしまうっての行けてない。やはりエラーにすべきなのでしょうな。

2010-05-19 19:30:44
tnozaki @tnozaki

@_taca_ 逆、そのケースはアプリケーションのバグとして早い時期に発覚しませんかね

2010-05-19 19:35:33
tnozaki @tnozaki

エラーにならないと思われていた動作がエラーになる方がソース互換性を失うのでやばい

2010-05-19 19:37:46
tnozaki @tnozaki

clarify undefined behavior するなら関数名を変えてしまうのが無難といえば無難

2010-05-19 19:44:07
tnozaki @tnozaki

unsetenv(3)のプロト変更といい軽率だとおもいますの、TOG仕事しろ

2010-05-19 19:46:48
tnozaki @tnozaki

ソース互換ならコンパイラがエラーチェックを強制する技があるけど、コンパイル済のバイナリには無力

2010-05-19 19:57:43
Takahiro Kambe @_taca_

@tnozaki 発覚すればよいのですが、見落とされた上に変にセキュリティの穴の原因にならないかしら?

2010-05-19 19:58:04
tnozaki @tnozaki

@_taca_ それはテスト不足なので、正しかったはずのテストが

2010-05-19 20:04:32

コメント

成瀬 @nalsh 2010年10月31日
久しぶりにNetBSD current更新してRubyのtest-all走らせたら、setenvでこけとる。http://www.hi-matic.org/diary/?20100925#25-1 の話か。とりあえず失敗のままで様子見
0
まさゃん(17) @DrFaust 2012年8月7日
こんなことも、あるんだ・・
0