[debian-users:12213] Re: historical info

["Ken N." <kenn@xxxxxxxxxxxxxxxxx>]

In <19990123023104C.oka@debian.or.jp>
[debian-users:12170] Re: historical info, Jan.23 '99 02:31 JST
oka@debian.or.jp says:
=   
=   極端な例で構わなければ、今書けます。パッケージとしてインストー
=   ルされたアプリケーションが致命的なバグを抱えていて、dpkg の
=   管理管轄のディレクトリに無作法に書き込みをしたり(suid 指定で
=   root で動くなどが必要ですが)、さらに極端な場合は dpkg が保持
=   している情報(/var/lib/dpkg 以下)を破壊した場合が考えられます。

まず、トロイアン・ホース・アタックのような極端なものは別の問題
とあわせて考えなければならないので、とりあえず横においておきま
しょう。euid==0 のプロセスによるcorruptionはもちろん考えられま
すが、さらに一般的に、たとえばHDD physical crashとかでも管理デー
タ破壊は起こる可能性はあります。

どこまで緻密にシステム管理するかによっては、システム監査や運用
でもこれらの管理データを保護しなくてはならない場合もあるかもし
れませんが、一般的にはシステム現状から管理データを復元する仕組
みがあればよさそうです。news-recovery(8)のような。


=   それでなくても、大なり小なり、一貫性の破壊は起こり得るような
=   気がします。アプリケーションがデータベースを作成したものの、
=   アンインストールされて、データベースが残ってしまったというの
=   も、システムは不健康な状態にあると言えそうです(普通は purge
=   の時に postrm あたりで削るのかな)。

あ、それ、アプリケーションのデータベースですよね。例えばINNを
アンインストールしたのに/var/lib/news/history が残っちゃったと
かですよね。それ、管理対象として考えてないです私は。

あとは何かな。
パッケージに嘘つかれて、インストール後にシステム現状と管理デー
タが矛盾するような場合かな。一貫性が保たれているかどうかを検査
できる仕組みが要りそうですね。


今日は余談は省略して、

=   # さて、議論がいかに形になるかがネックになりそう...。

うーん、やっぱり実装が必要なのかな、と思います。樽石さんのアイ
ディアも面白いし、岡さんのアイディアもどんな形にまとまるのか見
てみたい、私は私でインテグリティとパッケージの簡素化をつきつめ
たいし。

実装が無理なら、分析と設計をちょっと具体的に考えて交換してみる
とか。

＃UML で書けます？tgifかdia かなんか。


 -.- . -. -.
Ken Nakagaki <kenn@xxxxxxxxxxxxxxxxx>
「会社は主にそれ自身の慣性によって前進している」-- Gerry Spence