「コアダンプ」の版間の差分
(同期) |
(同期) |
||
2行目: | 2行目: | ||
[[Category:セキュリティ]] |
[[Category:セキュリティ]] |
||
[[en:Core dump]] |
[[en:Core dump]] |
||
− | [[wikipedia:ja:コアダンプ|コアダンプ]]とは突然プロセスが終了したときのプロセスのアドレス空間 (メモリ) を記録するファイルです。コアダンプは終了時に自動的に生成されるだけでなく、([[#コアダンプの作成|デバッガ]]などによって) 必要に応じて生成される場合もあります。コアダンプはプログラムのクラッシュに対する反応としてカーネルによって引き起こされ、([http://www.freedesktop.org/software/systemd/man/systemd-coredump.html systemd-coredump] などの) ヘルパープログラムに渡されて処理されます。 |
+ | [[wikipedia:ja:コアダンプ|コアダンプ]]とは突然プロセスが終了したときのプロセスのアドレス空間 (メモリ) を記録するファイルです。コアダンプは終了時に自動的に生成されるだけでなく、([[#コアダンプの作成|デバッガ]]などによって) 必要に応じて生成される場合もあります。コアダンプはプログラムのクラッシュに対する反応としてカーネルによって引き起こされ、([http://www.freedesktop.org/software/systemd/man/systemd-coredump.html systemd-coredump] などの) ヘルパープログラムに渡されて処理されます。コアダンプは普通のユーザーにとってはあまり意味をなしませんが、開発者がユーザーにコアダンプの提出を要求することがあります。問題を再現することが難しいような場合、クラッシュ時のプログラムの状態を検死する手段としてコアダンプは有用です。 |
== 自動的なコアダンプの無効化 == |
== 自動的なコアダンプの無効化 == |
||
14行目: | 14行目: | ||
[[systemd]] はデフォルトで全てのプロセスのコアダンプを {{ic|/var/lib/systemd/coredump}} に生成します。{{ic|/etc/systemd/coredump.conf.d/}} ディレクトリに以下の内容で設定スニペットを作成することで生成しないようにすることが可能です [http://www.freedesktop.org/software/systemd/man/coredump.conf.html#Description][https://bbs.archlinux.org/viewtopic.php?pid=1211433]: |
[[systemd]] はデフォルトで全てのプロセスのコアダンプを {{ic|/var/lib/systemd/coredump}} に生成します。{{ic|/etc/systemd/coredump.conf.d/}} ディレクトリに以下の内容で設定スニペットを作成することで生成しないようにすることが可能です [http://www.freedesktop.org/software/systemd/man/coredump.conf.html#Description][https://bbs.archlinux.org/viewtopic.php?pid=1211433]: |
||
− | {{hc|/etc/systemd/coredump.conf.d/custom.conf| |
+ | {{hc|/etc/systemd/coredump.conf.d/custom.conf|2= |
− | + | [Coredump] |
|
Storage=none}} |
Storage=none}} |
||
66行目: | 66行目: | ||
{{Note|完全なディスク暗号化をしていない場合、上記したことはプログラムのメモリがディスクにそのまま書き出されるということを意味します。たとえスワップを暗号化していてもコアダンプから情報が漏洩してしまう可能性があります。}} |
{{Note|完全なディスク暗号化をしていない場合、上記したことはプログラムのメモリがディスクにそのまま書き出されるということを意味します。たとえスワップを暗号化していてもコアダンプから情報が漏洩してしまう可能性があります。}} |
||
− | journal からコアダンプを取得する方法は {{ |
+ | journal からコアダンプを取得する方法は {{man|1|coredumpctl}} を見てください。 |
== コアダンプの確認 == |
== コアダンプの確認 == |
2018年1月7日 (日) 17:13時点における版
コアダンプとは突然プロセスが終了したときのプロセスのアドレス空間 (メモリ) を記録するファイルです。コアダンプは終了時に自動的に生成されるだけでなく、(デバッガなどによって) 必要に応じて生成される場合もあります。コアダンプはプログラムのクラッシュに対する反応としてカーネルによって引き起こされ、(systemd-coredump などの) ヘルパープログラムに渡されて処理されます。コアダンプは普通のユーザーにとってはあまり意味をなしませんが、開発者がユーザーにコアダンプの提出を要求することがあります。問題を再現することが難しいような場合、クラッシュ時のプログラムの状態を検死する手段としてコアダンプは有用です。
目次
自動的なコアダンプの無効化
コアダンプの自動生成を無効化する理由としては以下のようなことが考えられます:
- パフォーマンス: メモリの消費が激しいプロセスのコアダンプを生成するとき、システムリソースが浪費され、メモリの消去が遅延します。
- ディスク容量: 圧縮されない場合、コアダンプはメモリの使用量と同じ分だけ、あるいはそれ以上のディスク容量を消費します。
- セキュリティ: コアダンプは基本的に root しか読みことができないものですが、クラッシュの後にディスクに書き込まれた機密情報 (パスワードや暗号鍵など) が含まれている可能性があります。
systemd を使う
systemd はデフォルトで全てのプロセスのコアダンプを /var/lib/systemd/coredump
に生成します。/etc/systemd/coredump.conf.d/
ディレクトリに以下の内容で設定スニペットを作成することで生成しないようにすることが可能です [1][2]:
/etc/systemd/coredump.conf.d/custom.conf
[Coredump] Storage=none
それから systemd の設定をリロードしてください:
# systemctl daemon-reload
システム上にコアダンプを自動的に作成する他のプログラムが存在しなければ、上記の設定だけでユーザー空間のコアダンプを無効化できます。
ulimit を使う
コアダンプの上限容量は ulimit によって決まります。ulimit をゼロに設定すればコアダンプは完全に無効化されます [3]:
/etc/security/limits.conf
* hard core 0
sysctl を使う
sysctl を使うことで fs.suid_dumpable
カーネルパラメータを変更することができます。変更は suid プロセスだけに適用されます [4]。
/etc/sysctl.conf
fs.suid_dumpable = 0
コアダンプの作成
任意のプロセスでコアダンプを生成したい場合は、まず gdb パッケージをインストールしてください。そして実行しているプロセスの PID を確認してください。例えば pgrep を使って:
$ pgrep -f firefox
2071 firefox
確認されたプロセスにアタッチ:
$ gdb -p 2071
そして (gdb)
プロンプトで以下を実行:
(gdb) generate-core-file Saved corefile core.2071 (gdb) quit
上記の例では core.2071
という名前のコアダンプファイルが生成されています。
コアダンプの保存場所
sysctl の kernel.core_pattern
は自動的に生成されたコアダンプの保存場所を決定します:
$ cat /proc/sys/kernel/core_pattern |/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e
/usr/lib/sysctl.d/50-coredump.conf
のデフォルト設定では、コアダンプはシステムログとして journald に全て送信されます。
journal からコアダンプを取得する方法は coredumpctl(1) を見てください。
コアダンプの確認
存在するダンプは coredumpctl を使って確認します:
# coredumpctl list
ダンプは一意に識別する必要があります。PID
や実行ファイルの名前、実行ファイルのパスや journalctl の述部で指定することができます (詳しくは coredumpctl(1)
や journalctl(1)
を参照)。コアダンプの詳細を確認するには:
# coredumpctl info match
"Signal" 列を注視することでクラッシュの原因の解明に役立ちます。gdb を使ってバックトレースを確認してさらに細かい解析をすることも可能です:
# coredumpctl gdb match
gdb を起動したら、bt
コマンドを使ってバックトレースを出力してください:
(gdb) bt
参照
- american fuzzy lop - カーネルやプログラムのテストを自動化するツール
- Filesystem fuzzing - ファイルシステムのバグをテストする LWN の記事