Ubuntu Serverで『shred /dev/sda』を実行

シュレッダー『shred』

UNIX系OSでは、さまざまなリソースをファイルという形で抽象化する。ディスクも「/dev/名前」というファイルとして抽象化されている。shredコマンドでディスクを対象にすれば、ディスクをシュレッダーにかけることが可能になるだろう。実際には、こんな操作をすることは一生ないと思うが、機密データが含まれたディスクを破棄したい時などに利用できるかもしれない。

物は試しだ。ここでは連載の主旨に従って実行してみよう。

Ubuntu Serverでshred /dev/sdaを実行

Ubuntu Server 18.04 LTSでshredコマンドを実行してみる。

• Ubuntu Server 18.04 LTS

dfコマンドで調べると、/dev/sda2が/にマウントされていることがわかる。つまり、/dev/sda2に対してshredコマンドを実行すると、/以下がズタボロの状態になるということになる。

• /dev/sda2が/にマウントされていることを確認

この状態でshred /dev/sda2を実行してしばらくすると、次のようにファイルシステムエラーが頻繁に出るようになる。

• shred /dev/sda2を実行中にファイルシステムエラーが出続ける

• shred /dev/sda2コマンド実行完了

この状態でいろいろなコマンドを実行してみると、キャッシュに載っていると見られるコマンドは実行できるものの、そうでないコマンドを実行しようとしたり、シェルの組み込みコマンドであってもファイルシステムにアクセスするような処理を実行しようとしたりすると、次のようにファイルシステムエラーが表示され、何も実行されないことを確認できる。システムとしてはもう使い物にならない。

• ファイルシステムエラーが出て実行できない

shutdownコマンドでシステムを終了することもできないので、物理的に電源を入れ直してシステムを再起動する。すると、次のようにブートローダであるGrubからファイルシステムを認識できないというエラーが表示される。

• Grubがファイルシステムを認識できない

Grubから操作を行ってみても、対象のファイルシステムが認識できていないことを確認できる。

• Grubから操作してもファイルシステムレベルで認識できていないことがわかる

『rm -rf /』を実行した時は、ファイルシステム自体は壊れずに存在していた。しかし、shredコマンドを使ってデバイスファイルを対象にしてシュレッダー処理を行ってしまうと、ファイルシステムもろとも上書きが行われるため、もはや手が付けられない状態になることがわかった。

デバイスファイルにshredを実行してはいけない

そもそもデバイスファイルに直接コマンドで操作を行うことは、ある程度仕組みがわかってきてからじゃないとしないものだ。シェルスクリプトの誤りや人為的ミスで、こうした操作をする可能性はrm -rf /よりも低いのではないかと思う。

ただし、守秘義務契約のあるデータが含まれたUSBメモリをshredで処理しようとして、誤ってメインのディスクを壊してしまう、といったことはありそうだ。特に疲れている時にこのような操作を行うとシステムを壊しかねない。デバイスファイルに対してshredを実行する時は十分に確認したほうがよい。