第15回「フォールトインジェクションノススメ」が掲載されました。使ってエラーを発生させるというちょっと怖いお話です。ここでは目を離した隙にカーネルの挙動が変化しているという別の方向で怖い話をしたいと思います。カーネルにバックポートされましたが、修正されたことを知るのは面倒です。いうのも、エラータのページにはセキュリティ上の不具合の修正内容についてしか言及されておらず、「その他の修正内容についてはテクニカルノートを見てね」と書かれているのに従ってテクニカルノートのページをチェックしても、今回の不具合に該当しそうな内容が見当たりません。パッケージの変更履歴の説明文をチェックするかソースコードの差分をチェックして初めて、「あ、修正されたんだな」と判るようになっていたのです。テクニカルノートには全修正内容が網羅されていると思っていると、落し穴にはまるかもしれないということですね。発動させずに諦めるという変更が適用されてしまいました。リリースされるまでにマージするというのが本来の手順なのですが、その手順をすっとばされた訳です。ファイルシステムより低いレイヤーでのメモリ割り当てがメモリ枯渇時に失敗してしまうようだと、ファイルシステムエラーが多発してしまうので困ると思うのですが。必要な個所を全て洗い出して修正してからにしてほしかったんだけどなぁ。)の影響範囲の調査方法について」が掲載されました。ルイージ@お化け屋敷のような、次から次へと襲い掛かってくる問合せの嵐に困っています。脆弱性を機に、緊急コラムとして調査方法を説明することにしました。一昨日考えた内容を急いでダンプしたものなので、全てを網羅できている訳ではありません。影響範囲を調査することの難しさに気付いて素直にアップデートをしていただけるのなら、この記事を作成した意味はあると考えています。今回の脆弱性については幽霊に振り回されすぎている感がありますが、システムの動作を再確認してみるチャンスかもしれません。任意のホスト名を渡すことができるかどうかをソースコードレベルで網羅的に調査してみたら、OSコマンドインジェクションのような、今まで見落としていた脆弱性が見つかってもおかしくないと思っています。ススメ」が掲載されました。使って挙動を追跡するというお話です。起動してから約70秒後にシステムが予期せぬ再起動をしてしまうというトラブルが発生していました。タイムアウトによるリセットが発生しているのではないかと疑ったのですが、原因を掴めませんでした。スクリプトを仕掛けて事象を再現してもらいました。書き込んだことによるリセットが発生していたことが判明したのです。これをきっかけに、設定の誤りが予期せぬ再起動の原因であったことが判明し、トラブルを解決することができました。呼び出しているようです。書き込んでいるようです。デーモンにログメッセージを出力する方法には、2つの落し穴があったのです。デフォルトで非同期書き込みを行うようになっている点です。そのため、非同期書き込み後すぐに再起動要求が発生してしまっては、ログに残すことができません。関数が復帰してしまうため、たとえ同期書き込みを行うようになっていたとしても、同期書き込みの完了を待たずに再起動要求が発生してしまい、ログに残すことができません。登場により、3つ目の落し穴も発見されました。行われなくなっています。ログが残っていないという可能性が一層高くなっています。デーモンに頼っていては駄目なのかもしれません。システムが増えてくるに従い、問題事象発生時のログを如何に残すかという課題が出てきそうです。経由で取得するという方法が使えます。アップデートは〜内〜。