ぜんぜん別件だけど
むかし誰かに load averageがアンダーフローして数億になってる。というバグ報告をいただいたのだが誰から聞いたのか思い出せん。たぶん一年ぐらいまえ。とりあえず、sched_setscheduler()にレースがあることが分かって、治したので今後はおきないはず。
ではでは
むかし誰かに load averageがアンダーフローして数億になってる。というバグ報告をいただいたのだが誰から聞いたのか思い出せん。たぶん一年ぐらいまえ。とりあえず、sched_setscheduler()にレースがあることが分かって、治したので今後はおきないはず。
ではでは
- 関連記事
-
- gcc 4.7 だとカーネルがまともに動かないんじゃないの？という話 (2012/02/02)
- load averageのアンダフローバグ (2012/01/31)
- 3.1からRLIMIT_NPROCの挙動が変わった件について (2012/01/31)
小ネタ
3.1からLinux の RLIMIT_NPROC のあつかいがちょっと変わります。端的にいうとNetBSDちっくな動きになりました。
まずバックグランドを説明すると、NPROCはユーザあたりのプロセス数を制限する機能であると。端的にいうとプロセス数超過するとforkがEAGAIN返して失敗する。プロセスを作る方法は１つしかないから一見自明に見える。
ところが「ユーザあたりのプロセス数」というのがキモで、プロセスの所有ユーザを変えてしまうという手がある。set*uid() 族と setuidされたプログラムに対するexec()族である。
余談。従来Linuxはset*uid()族はNPROCチェックをしてEAGAINを返していたが、execではチェックしていなかった。ついでにいうとforkでのチェックもちゃんとロックされてなかったので、プロセス数の厳密な保証はもとから無かった。NPROCなんてしょせんforkbomb対策のオモチャだから適当でいいんだよ。というのはLinusの弁。まあ、それは置く。
set*uid()でチェックすると何が問題かというと、POSIX的にはset*uid()は正しい引数を与える限りにおいて失敗しないので、かなり著名なソフトでも誰も返値をチェックしてない。ついでにいうとLinuxはmanページからしてEAGAINの記載がないというていらくで（※ごめん、いま見直したらmanにはちゃんと書いて有ったわ）エスパーでもない限り失敗するケースを思いつく人はいないという状況だった。
さて、set*uid()を使う場面というのは（ごく一部の例外を除いて）端的に言えばrootが非rootに変身して権限を落とすということであるので、ここで失敗してかつエラーチェックを怠るとroot権限をもったまま信頼できないプログラムをexecするアホdaemonが出来上がる。
で、権限を落とすシステムコールを失敗させるのはセキュリティ的にたいへん危険なので、権限昇格させるほう、つまりexec族で失敗させるのが正しいんじゃね？という意見が提出された。普通のデーモンは fork - setuid - exec の３つをつづけて呼ぶのでチェックがsetuidからexecに変わっても、実質の動きはかわらんでしょう、と。
で、いつものように互換性がにゃーにゃー、戻り値をチェックしないプログラムがワンワンと騒いでいたのだが、たまたまtwitterでsodaさんがNは何年も前からexecでチェックしてるとつぶやいていたのでLinusに転送してみたら採用されてしまった。
そのあと互換性議論が復活して、setuid使ってないプロセスはexec失敗しないよう仕様が若干変更され、現在の使用は
・set*uid()時にNPROC超過を検出し、かつ
・その後のexecでも再びNPROC超過を検出したとき
のみexecがEAGAINを返す。となっている
というわけで、この件でなにか困った事にぶちあたった人がいたらsodaさんをdisるといいと思うよ。
・・・という免責事項を軽くジャブしたあとでいうのもなんですけど、NetBSDのみなさんはRLIMIT_NPROCのコメントやドキュメントで「Linuxと違ってNetBSDはhogehoge」などと説明してるところをいちいち治して回る刺身たんぽぽの作業をするといいと思うよ。ではでは
以下はLinus treeに入ってるコミットログ
3.1からLinux の RLIMIT_NPROC のあつかいがちょっと変わります。端的にいうとNetBSDちっくな動きになりました。
まずバックグランドを説明すると、NPROCはユーザあたりのプロセス数を制限する機能であると。端的にいうとプロセス数超過するとforkがEAGAIN返して失敗する。プロセスを作る方法は１つしかないから一見自明に見える。
ところが「ユーザあたりのプロセス数」というのがキモで、プロセスの所有ユーザを変えてしまうという手がある。set*uid() 族と setuidされたプログラムに対するexec()族である。
余談。従来Linuxはset*uid()族はNPROCチェックをしてEAGAINを返していたが、execではチェックしていなかった。ついでにいうとforkでのチェックもちゃんとロックされてなかったので、プロセス数の厳密な保証はもとから無かった。NPROCなんてしょせんforkbomb対策のオモチャだから適当でいいんだよ。というのはLinusの弁。まあ、それは置く。
set*uid()でチェックすると何が問題かというと、POSIX的にはset*uid()は正しい引数を与える限りにおいて失敗しないので、かなり著名なソフトでも誰も返値をチェックしてない。
さて、set*uid()を使う場面というのは（ごく一部の例外を除いて）端的に言えばrootが非rootに変身して権限を落とすということであるので、ここで失敗してかつエラーチェックを怠るとroot権限をもったまま信頼できないプログラムをexecするアホdaemonが出来上がる。
で、権限を落とすシステムコールを失敗させるのはセキュリティ的にたいへん危険なので、権限昇格させるほう、つまりexec族で失敗させるのが正しいんじゃね？という意見が提出された。普通のデーモンは fork - setuid - exec の３つをつづけて呼ぶのでチェックがsetuidからexecに変わっても、実質の動きはかわらんでしょう、と。
で、いつものように互換性がにゃーにゃー、戻り値をチェックしないプログラムがワンワンと騒いでいたのだが、たまたまtwitterでsodaさんがNは何年も前からexecでチェックしてるとつぶやいていたのでLinusに転送してみたら採用されてしまった。
そのあと互換性議論が復活して、setuid使ってないプロセスはexec失敗しないよう仕様が若干変更され、現在の使用は
・set*uid()時にNPROC超過を検出し、かつ
・その後のexecでも再びNPROC超過を検出したとき
のみexecがEAGAINを返す。となっている
というわけで、この件でなにか困った事にぶちあたった人がいたらsodaさんをdisるといいと思うよ。
・・・という免責事項を軽くジャブしたあとでいうのもなんですけど、NetBSDのみなさんはRLIMIT_NPROCのコメントやドキュメントで「Linuxと違ってNetBSDはhogehoge」などと説明してるところをいちいち治して回る刺身たんぽぽの作業をするといいと思うよ。ではでは
以下はLinus treeに入ってるコミットログ
commit 72fa59970f8698023045ab0713d66f3f4f96945c
Author: Vasiliy Kulikov
Date: Mon Aug 8 19:02:04 2011 +0400
move RLIMIT_NPROC check from set_user() to do_execve_common()
The patch http://lkml.org/lkml/2003/7/13/226 introduced an RLIMIT_NPROC
check in set_user() to check for NPROC exceeding via setuid() and
similar functions.
Before the check there was a possibility to greatly exceed the allowed
number of processes by an unprivileged user if the program relied on
rlimit only. But the check created new security threat: many poorly
written programs simply don't check setuid() return code and believe it
cannot fail if executed with root privileges. So, the check is removed
in this patch because of too often privilege escalations related to
buggy programs.
The NPROC can still be enforced in the common code flow of daemons
spawning user processes. Most of daemons do fork()+setuid()+execve().
The check introduced in execve() (1) enforces the same limit as in
setuid() and (2) doesn't create similar security issues.
Neil Brown suggested to track what specific process has exceeded the
limit by setting PF_NPROC_EXCEEDED process flag. With the change only
this process would fail on execve(), and other processes' execve()
behaviour is not changed.
Solar Designer suggested to re-check whether NPROC limit is still
exceeded at the moment of execve(). If the process was sleeping for
days between set*uid() and execve(), and the NPROC counter step down
under the limit, the defered execve() failure because NPROC limit was
exceeded days ago would be unexpected. If the limit is not exceeded
anymore, we clear the flag on successful calls to execve() and fork().
The flag is also cleared on successful calls to set_user() as the limit
was exceeded for the previous user, not the current one.
Similar check was introduced in -ow patches (without the process flag).
- 関連記事
-
- load averageのアンダフローバグ (2012/01/31)
- 3.1からRLIMIT_NPROCの挙動が変わった件について (2012/01/31)
- git のsha1は何桁あれば安全か (2011/12/28)
http://www.ipa.go.jp/software/open/ossc/seika_1005_1.html
あとでみる。
あとでみる。
- 関連記事
-
- はてなのブログパーツはずしました (2012/03/12)
- IPAの教材「RubyによるWebアプリケーション開発 教育プログラム導入実証」 (2012/01/04)
- はてぶボタンをリニューアルした (2010/11/27)
http://d.hatena.ne.jp/nagachika/20111231/ruby_trunk_changes_34162_34165
ハハッ・・・そんなばかな。ばかな・・・・
そんなにコミットしているわけがない。集計方法の問題ということにしておこう
2011年最後の ruby trunk changes です。今日は LLVM 向けの最適化避け、rb_barrier_t の不具合修正などがありました。
今年は 3155 コミットありました。コミット数 1位はもちろんわれらがパッチモンスター nobu (583 commits), 2位は svn さん(348 commits)、3位は kosaki さん(332 commits)でした。コミッターのみなさん今年もお疲れさまでした!
ハハッ・・・そんなばかな。ばかな・・・・
そんなにコミットしているわけがない。集計方法の問題ということにしておこう
- 関連記事
-
- RubyとArgumentError (2012/02/10)
- どうしてこうなった (2012/01/01)
- RubyKaigi2011で発表してきました (2011/07/18)