FreeBSD セキュリティアドバイザリ: mksnap_ffs が重要な設定を消去 27
ストーリー by wakatono
心当たりの人は対処を 部門より
心当たりの人は対処を 部門より
BSD 曰く、 "
FreeBSDより出された
セキュリティアドバイザリによると、
mksnap_ffs(8) を使用するとマウント中のファイルシステムの
重要なフラグ類がクリアされ、セキュリティ的に非常に危険な
状態になるため、システムを更新するように求めている。
マウントされたファイルシステムには、
ファイルシステム内のバイナリの実行を制限したり、
アクセス許可ビットを補完するACL(アクセス制御リスト)機能を
組込んだりしているフラグが存在する。
mksnap_ffs(8) はスナップショットファイルを作成するが、
これは使用中のファイルシステムのある一時点での状態を
静的に固定化したものであり、 fsck(8) や dump(8) を
起動する時に必要となる。
今回、この mksnap_ffs(8) にバグが発見されたわけである。
もし、システム稼動中に定期的にバックアップして
いるならば、すぐにそれを停止する必要がある。
FreeBSD 5.1 と 5.2 には、パッチされたバージョンが
準備されているので、早速更新すべきであろう。"
バグの詳細 (スコア:4, 参考になる)
どっちみち私は 4.9 ユーザなので関係ないなぁ。っていうか STABLE でないものをそんな重要なところで運用するチャレンジャーはそうはいないのでは。
Re:バグの詳細 (スコア:1, 興味深い)
元記事にあるように fsck に影響があるのなら、
CURRENT(unstable) だからこそ重要な問題と言えるのかもしれませんね。
同じ意見 (スコア:0)
影響範囲 (スコア:2, 参考になる)
5.2.1? (スコア:0)
今5.2.1-RCになってますね。ata周りの改善も入って新しい
ブランチになるんでしょうか。
FreeBSD 5.2.1-RC (スコア:2, 参考になる)
運用中のシステムのバックアップ作業 (スコア:1, オフトピック)
- 夜間休日等にシングルユーザモードに移行して dump する。
- 夜間等にマルチユーザモードのまま、mount状態で dump する。
- 夜間等にマルチユーザモードのまま、tar する。
- バックアップしない。
運用中のシステムと言っても、業務システムだったり、仲間うちの メールサーバだったりと運用レベルが様々でしょうから、一概に こうとは言えないことと思います。ちなみに僕はメール サーバは2の方法でやっています。バックアップファイルがまともに 使えないかもしれないことは覚悟の上です。Re:運用中のシステムのバックアップ作業 (スコア:2, 参考になる)
更新頻度やらで、バックアップに求められることも変わる
わけでして、そこらへんは「一概にこうやる」はないと...
>1. 夜間休日等にシングルユーザモードに移行して dump する。
これは、大概のシステムのカットオーバ時点や、安定期に入った
時点や、システムの更新が入った時点で取得しておかないとね。
あとはアプリを含めたデータ領域については、定期的に手段を
見てやっておくね。
あと、２４時間の稼働が求められるシステムなんかだとスナップ
ショットに頼ったりすることもありますが、DBMSなんかの
ログのバックアップ機能と併用してのバックアップが必要に
なったりしますね。
# ログが大量にあるので、ログから復旧するのに半日以上とか
# あったり...戻るだけましか...
Re:運用中のシステムのバックアップ作業 (スコア:1, 興味深い)
くさくないですか？
私は必要なデータに限定して定期的に物理的に違うディスクに cp
（まぁそれっぽいアプリだったり rsync だったり）して、要するに
丸っきり同じものを増やしてるだけです。tar とか挟む必要感じないし、
手間が増えると戻すの面倒だし。
世代とか考える必要があるならもう一工夫要りますが、面倒なら
バックアップのバックアップを用意してタイミングずらして cp
しとくだけでも少しはマシです。
DB とか絡むともっと手間が要るんでしょうけど。
自宅サーバはバックアップマシンもバックアップディスクもないので
放置中。（基本的に自分専用なんで。）そろそろディスク増やそうかな。
Re:運用中のシステムのバックアップ作業 (スコア:1)
/etc の下をちょっとセーブするだけなら cp でも良いと思うので すが、ファイルの個数が多い時や差分ダンプしたい時は、やはり dump の方が良いような気がします。ましてや、全ダンプしたい 時は tar や cp では無理なような気がします。(先入観でしょうか)
最近は磁気テープにバックアップせずに別のディスクに保存したり するので、本当にバックアップになっているのか、自分でも疑問に 思うことがあります。
Re:運用中のシステムのバックアップ作業 (スコア:0)
>操作するだけです。面倒という人もいるかもしれませんが、僕は慣
>れてしまっているので、簡単な作業だと思っています。
restore しないと中身確認できなくないですか？
戻してからやっぱこれじゃないとかってなると面倒かなということ
なんですよ。
あと、システム全部って要求がそもそもないのでアレですが、cp と
いうのはそれ系ってだけで実際 cp は使っていません。というのも
挙げた方法は OS に依存しないものでして。例えばWindows なら
ちょっと賢い程度の cp みたいなアプリはあるでしょ。それを使い
Re:運用中のシステムのバックアップ作業 (スコア:1)
これが面倒ということでしたら、同じようにファイルシステムにコピーする といった手段以外は取れないでしょう。結局、バックアップの目的がほんとの 緊急時に備えるだけなのか、ちょっとした失敗を簡単に回復できるようにしたい かどうか。
> Unix なら rsync とかになります。cp でやりたいとは思いません。
> tar は dump, restore と同じ理由で面倒な感じがします。
あとは要求仕様的な問題で、
- holeのあるファイルをcareするかどうか。
- バックアップによってmtimeが更新されるのを良しとするかどうか。
といったあたりで、dumpとそれ以外を選ぶかは決めるとよろしかと。Re:運用中のシステムのバックアップ作業 (スコア:0)
バックアップ先が、それなりに遠隔地にあるのなら大丈夫でしょう
#無論、保存先の名称はある程度変更して複数持つのを前提として..
HDDのみでバックアップする場合に注意しなければいけない
Re:運用中のシステムのバックアップ作業 (スコア:1)
データファイルもファイルシステム全部のバックアップは面倒なので、必要なデータ(変更が常に行われているデータ)を
抽出してそれだけtar等で圧縮してバックアップしてます。
# 自分のマシンは、バックアップすら取ってないです(やば
Re:運用中のシステムのバックアップ作業 (スコア:0)
これはバックアップ上、無意味だと思いますが。
復旧できないバックアップって、ただのコストにしかならない。
・バックアップ作業というのは、「バックアップをする」のではなく「復旧する」のが目的では？
Re:運用中のシステムのバックアップ作業 (スコア:2, 参考になる)
>これはバックアップ上、無意味だと思いますが。
これは可能性の問題なんだよね。極端を言えば、「テープが
壊れる」などのバックアップ先の媒体が壊れる「かもしれな
い」というのは、可能性としてあるわけです。それに対して
覚悟があろうがなかろうが、それがあるからと言ってバック
アップ上では無意味とはいえないわけなんですよ。
>バックアップ作業というのは、「バックアップをする」のではなく「復旧する」のが目的では？
２４時間オンライン稼働を求められるシステムで、さらに
バックアップを求められる場合、当然、復旧を含めて導入
時や構成変更時に、復元の試験などを行い、復元が出来る
事(が、少なくともその試験であった事)は確認する程度は
やらないといけないでしょう。
完全を求めて、不完全である可能性をもって確率を上げる
ことを拒絶しては、ほとんど何も進みませんね。
# そもそも最初が完全であればバックアップなんぞも不要な
# わけなんですよね。
Re:運用中のシステムのバックアップ作業 (スコア:0, 荒らし)
バックアップ中に作成/変更されたファイル/ディレクトリが
・バックアップされない
・内容が
Re:運用中のシステムのバックアップ作業 (スコア:1)
テープが物理的／電気的にダメージを食らわないという根拠は
どこにあるのでしょう？ドライブがテープを噛み込んでしまっ
たらどうするおつもりですか？
そういった事故にあなたは会われたことがないのは大変、幸運
なことですが、あいにくとわたしはそういったことを何件か
食らっておりまして... あなたの様に無意味な自信を持つなんて
ことは、怖くてできません。
>結局、「書き換えつつあるファイル群を cp -p -R で コピー
>したら、どのように壊れたコピーが得られるか」というの と同じ。
何か、議論の論点がずれていますね。
「壊れたファイルが得られる可能性が低い深夜に、バックアップ
としての安全性を高めてdumpする」といったことが、なぜ「(時
を問わず)単にcp -p -Rで複製するだけ」と同じといったことに
すり替わるのか、ちょっと不思議なんですよ。
つまり、安全を絶対のものとして、考えているのかな？それは、
ある種の「安全神話」を引き起こすことになりますよ。
# あくまで確率とそれを高めるための持続的な対応と、それに
# かかるコストとのやりとりになるわけなんですよ。
バックアップとってあるから安全です！とか言っていて、実際
落ちたらバックアップテープが古過ぎてアーカイブログを戻す
といった作業を複数のテープセットで繰り返していたら、復帰
に１週間かかります,,なんてことがあったりします。「そんな
に待てないので、データ再エントリーする」という判断が下る
こともあったりするわけです。
実は、色々とシステムリソースや工数を使って完全に取得した
バックアップでも、実際には使えないバックアップであったと
いうこともあったりするわけなんですね。
Re:運用中のシステムのバックアップ作業 (スコア:1)
Re:運用中のシステムのバックアップ作業 (スコア:1)
ならば、そう書けばよろしい。さらに、その意見に対して応答を
付けないとね。わたしの「確率上での有意だ」という投稿に対し
て、
>dumpやtarなら、 出来たテープが潰れていることはないでしょう。あくまでもファイル単位。
で、デバイスの破壊などの場合について、わたしはあなたが応答
した投稿にて、「何でとっても全損の可能性がある」と指摘して
いるのに、何かしらでは有効であり、ファイル単位には破損する
程度と言い切っているのが、議論をややこしくしているという事
なんですけどね。
ということで、議論を継ぐ元の誤りと、さらにわたしの投稿にあ
る「媒体障害の場合の全損可能性」の事実提示に対して「ファイ
ル単位の破損だ」という誤った事を指摘してしまったのが、君の
ミスだと思うよ。
# つまり、ちぐはぐな応答の連綿と、さらに妙にそれで話が繋がる
# 誤った意見の提示ってことです。
yasudas語は意味不明 (スコア:0)
肝心の「有意だ」っていう点を示してないだろ。そう主張してるだけ。だいたい「確率上での有意」って一体どういう意味か不明だし。きっとyasudas語なんだろうが。
Re:運用中のシステムのバックアップ作業 (スコア:2, 参考になる)
バックアップと復旧って必ずしも「完全」を求められる場合だけではないです. 不完全な復旧, 例えばこの例にあるメールサーバの様な場合, 最新の数通が消失した程度ならごめんなさいで済む場合もあります.
そういう意味で「完全」復旧という前提ではまともに使えないバックアップファイルであっても, それなりの使い道があるということで運用上の考慮に加えた方が良いこともままあります. その点, dumpってファイルシステム上の一貫性だけは保持していたはずなので, メールサーバの場合ならMaildir形式と組み合わせればマルチユーザモードでもかなり安全性は高いはずです.
ちなみに私も家のサーバはdump+Bacula [bacula.org](マルチボリュームに対応しているみたいなので最近のどでかいストリームデータでもOKそう)でバックアップしようかと思って設計中です.
Re:運用中のシステムのバックアップ作業 (スコア:1)
Re:運用中のシステムのバックアップ作業 (スコア:0)
バックアップは、サブのシステムへ
ミラーリングする事で代用しています。
メディアへのバックアップは、
基本的に /home と postgreSQLのダンプのみを週に１回だけ
tarballにして支社で保管しています。
（火災等でデータが完全に消失するのを防ぐ為のみです）
この議論がオフトピ？ (スコア:0)
モデレートしてくれよ。
mksnap_ffsが運用中のファイルシステムのバックアップに使われ
ていて、それが使えないと運用中のバックアップができないという
議論をしているのに、「オフト
Re:運用中のシステムのバックアップ作業 (スコア:0)
FreeBSD-current で dump -L すればいいだけです。 と、今回の話につなげておく。
-current だと安定して動かすのが -stable より大変なのことが多いのですが、 それでも今動かしている 4-stable を置き換えたくなる理由の一つです。