diary)この広告は、90日以上更新していないブログに表示しています。v6のファイルシステム周りのコードを読みました。ファイルのクローズ・削除のあたりを読んでいたときに、あることに気づきました。PDP11を使った実験により、それを確かめてみました。削除したファイルの復元(?)も行ってみました。追記:このエントリを書き終ってから気づきました。emulatorにログインし、以下のような環境を構築しました。;}/workにhoge.cというファイルとそれをコンパイルして生成されたa.outというファイルが存在しています。quitコマンドでemulatorから抜けます。numberを確認します。numberを表します。numberがわかりました。次に、hoge.cのinode情報を見ます。toolで使用できるコマンドの一つで、inode情報を表示します。toolを終了します。次に、hexdumpコマンドを使って、ブロックデバイス中のhoge.cデータをを見てみます。アドレスの計算をします。なんとなくpythonを使って計算してみました。)'0x173c00'hexdumpコマンドを使って、ブロックデバイスの中身をダンプします。v6rootは、simh+PDP11で使用しているディスクイメージです。|................|*...snip...確かにデータが入っているのが確認できました。ファイルの削除処理シェルでrmが呼ばれたときのことを考えます。rm内部ではunlinkシステムコールが呼ばれます。)ではinodeの参照カウンタをデクリメントします。numberをフリーリストに戻します。numberもフリーリストに返します。これらの処理の結果をブロックデバイスに反映させます。これを実験で確認します。simh+PDP11のemulator環境にログインして、hoge.cを削除します。lsa.outそしてemulatorからログアウト。toolを起動します。adehoge.cは削除されているのが確認できます。0になっているのが確認できます。toolを終了させます。つづいてhexdumpコマンドを使ってブロックデバイスを直接覗いてみます。|................|*...snip...削除されたhoge.cのデータが、まだブロックデバイス中に残っているのが確認できます。ファイルの削除処理が行われると、inode情報は初期化されますが、データ自体はブロックデバイス中に残ったままになります。ついでにworkディレクトリについても見てみます。toolでworkディレクトリのinode情報を表示させます。つづいてアドレスの計算。)'0x183e00'hexdumpコマンドでダンプ。numberで、残りの14byteがファイル・ディレクトリ名です。numberはクリアされているのが確認できます。numberは0にセットされますが、ファイル・ディレクトリ名は残ったままになります。ファイルの復元処理ブロックデバイス(ディスクイメージ)から、hoge.cのデータを抽出します。こんなCのコードを書きました。;}このプログラムは、あるファイルのあるアドレスからサイズ分のデータを抽出します。抽出したデータは別ファイルに出力します。あとはこれを実行するだけです。該当データのアドレスはわかっていますし、サイズもinode情報を表示させたときに取得しています。;}このようにファイルの復元が実現できました。削除したファイルをブロックデバイスから抽出することに成功した、の方がより正しい言い方かもしれません。まとめと考察まとめ以下のことが実験で確かめられました。ファイルを削除するとinode情報はクリアされるデータ自体はブロックデバイスに残ったままファイル名もディレクトリに残ったまま完全にデータを消すにはでは、完全にデータを消す(二度と見られなくする)にはどうしたらよいでしょうか。こんな方法が考えられます。ファイルの中身をクリアしてからrmコマンドで削除する比較的簡単にそのようなプログラムを書くことができるでしょう。他にこんな方法もあります。numberが割り当てられます(おそらく)。データの復元についてファイルを削除しても、データはブロックデバイスに残ったままです。復元したいファイルのアドレスとサイズさえわかっていれば簡単に抽出が可能です。実践的なことを考えると、どうやってアドレスとサイズを取得するのかが悩みどころです。(ブロックデバイスのinode領域だけバックアップを取っておくとか?全体のバックアップを取っておくよりはコスト安なはず)また、前述のとおり、削除したファイルはすぐに上書きされてしまう可能性が高いので、削除してから時間が経ったファイルの復元は難しいでしょう。ファイル名の復元についてファイル・ディレクトリ名についても、そのファイル・ディレクトリが存在していたディレクトリさえわかれば再現は可能です。それがわからない場合は再現が難しいでしょう。データと同様に、ディレクトリにファイル・ディレクトリが追加されるとその情報が失われてしまうので、時間が経ったものも復元は難しいでしょう。データをクリアしないのか?おそらくレイテンシを気にしているのだと思います。inodeをクリアするだけならば、該当inodeが存在しているブロックを読み込み、inode情報を更新してからブロックを書き込み、と、ブロックデバイスに対して2回のアクセスで済みます。データ自体も消すとなると、データのサイズ次第ではさらに何回もブロックデバイスに対するアクセスが必要になります(ブロックデバイスのアクセス単位は512bytes)。それに、ファイルによって削除処理から戻ってくる時間が異なるのは、システムとしてあまりよくない設計だと思います。セキュリティ上データを完全に消したいファイルもあれば、そうでないファイルもあります。全てのファイルに対してデータをクリアする処理を加えるのは無駄であると言えるでしょう。上記の通り、意味のないデータで上書きをしてから削除する(rmコマンドを呼ぶ)というのはユーザのプログラムで行えます。「必要ならばユーザが独自にやってくれ」という思想なのではないでしょうか。終わりにファイル削除周りのコードを読んだ時に感じたことが、実験により確かめることができました。最新のOS環境でも「ファイルは消したが、データはハードディスクに残ったままで、そこから情報漏えいした」なんて話が聞こえてきます。今回確かめたことは最新の環境でも通じるところがあるのではないかと思っています。Physics月別アーカイブはてなブログをはじめよう!takahiroxさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。