「コアダンプ」の版間の差分
(→コアダンプの確認: 情報を更新) |
(他言語へのリンクを追加) |
||
(同じ利用者による、間の2版が非表示) | |||
2行目: | 2行目: | ||
[[Category:セキュリティ]] |
[[Category:セキュリティ]] |
||
[[en:Core dump]] |
[[en:Core dump]] |
||
+ | [[pt:Core dump]] |
||
+ | [[ru:Core dump]] |
||
[[wikipedia:ja:コアダンプ|コアダンプ]]とは突然プロセスが終了したときのプロセスのアドレス空間 (メモリ) を記録するファイルです。コアダンプは終了時に自動的に生成されるだけでなく、([[#コアダンプの作成|デバッガ]]などによって) 必要に応じて生成される場合もあります。コアダンプはプログラムのクラッシュに対する反応としてカーネルによって引き起こされ、([https://www.freedesktop.org/software/systemd/man/systemd-coredump.html systemd-coredump] などの) ヘルパープログラムに渡されて処理されます。コアダンプは普通のユーザーにとってはあまり意味をなしませんが、開発者がユーザーにコアダンプの提出を要求することがあります。問題を再現することが難しいような場合、クラッシュ時のプログラムの状態を検死する手段としてコアダンプは有用です。 |
[[wikipedia:ja:コアダンプ|コアダンプ]]とは突然プロセスが終了したときのプロセスのアドレス空間 (メモリ) を記録するファイルです。コアダンプは終了時に自動的に生成されるだけでなく、([[#コアダンプの作成|デバッガ]]などによって) 必要に応じて生成される場合もあります。コアダンプはプログラムのクラッシュに対する反応としてカーネルによって引き起こされ、([https://www.freedesktop.org/software/systemd/man/systemd-coredump.html systemd-coredump] などの) ヘルパープログラムに渡されて処理されます。コアダンプは普通のユーザーにとってはあまり意味をなしませんが、開発者がユーザーにコアダンプの提出を要求することがあります。問題を再現することが難しいような場合、クラッシュ時のプログラムの状態を検死する手段としてコアダンプは有用です。 |
||
− | {{Warning|コアダンプには機密データ |
+ | {{Warning|コアダンプには機密データ(パスワードや暗号キーなど)が含まれている可能性があるため、信頼できる相手としか共有しないでください。}} |
== 自動的なコアダンプの無効化 == |
== 自動的なコアダンプの無効化 == |
||
75行目: | 77行目: | ||
=== コアダンプの保存場所 === |
=== コアダンプの保存場所 === |
||
+ | {{ic|kernel.core_pattern}} [[sysctl]] は自動的にコアダンプの保存先を決定します。デフォルトでは、コアダンプは ''systemd-coredump'' に送信されます。これは {{ic|/etc/systemd/coredump.conf}} で設定できます。デフォルトでは、すべてのコアダンプは {{ic|/var/lib/systemd/coredump}} に保存され ({{ic|1=Storage=external}} のため)、{{ic|zstd}} で圧縮されます。({{ic|1=Compress=yes}} の場合) さらに、ストレージのさまざまなサイズ制限を設定できます。 |
||
− | [[sysctl]] の {{ic|kernel.core_pattern}} は自動的に生成されたコアダンプの保存場所を決定します: |
||
+ | {{Note|{{ic|kernel.core_pattern}} のデフォルト値は、{{ic|/usr/lib/sysctl.d/50-coredump.conf}} で設定されます。このファイルは、通常の {{man|5|sysctl.d}} ルールに従って別の設定を使用するようにマスクまたはオーバーライドされる場合があります。}} |
||
− | $ cat /proc/sys/kernel/core_pattern |
||
− | |/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e |
||
+ | journal からコアダンプを取得するには、{{man|1|coredumpctl}} を参照してください。 |
||
− | {{ic|/usr/lib/sysctl.d/50-coredump.conf}} のデフォルト設定では、コアダンプはシステムログとして journald に全て送信されます。 |
||
− | |||
− | {{Note|完全なディスク暗号化をしていない場合、上記したことはプログラムのメモリがディスクにそのまま書き出されるということを意味します。たとえスワップを暗号化していてもコアダンプから情報が漏洩してしまう可能性があります。}} |
||
− | |||
− | journal からコアダンプを取得する方法は {{man|1|coredumpctl}} を見てください。 |
||
== コアダンプの確認 == |
== コアダンプの確認 == |
||
96行目: | 93行目: | ||
{{ic|/var/lib/systemd/coredump/}} に保存されているコアダンプファイルは、{{ic|systemd-tmpfiles --clean}} によって自動的にクリーンアップされます。これは、{{ic|systemd-tmpfiles-clean.timer}} によって毎日トリガーされます。コアダンプは少なくとも 3 日間保持されるように設定されています。{{ic|systemd-tmpfiles --cat-config}} を参照してください。 |
{{ic|/var/lib/systemd/coredump/}} に保存されているコアダンプファイルは、{{ic|systemd-tmpfiles --clean}} によって自動的にクリーンアップされます。これは、{{ic|systemd-tmpfiles-clean.timer}} によって毎日トリガーされます。コアダンプは少なくとも 3 日間保持されるように設定されています。{{ic|systemd-tmpfiles --cat-config}} を参照してください。 |
||
− | == コアダンプ |
+ | == コアダンプの分析 == |
+ | |||
+ | まず、関連するダンプを一意に特定する必要があります。これは{{ic|PID}}、実行ファイル名、実行ファイルへのパス、[[journalctl]] 述語を指定することで可能です (詳細は {{man|1|coredumpctl}} と {{man|1|journalctl}} を参照) コアダンプの詳細を見るには |
||
+ | |||
+ | # coredumpctl info ''match'' |
||
+ | |||
+ | クラッシュの原因を特定するのに役立つ "Signal" 行に注目してください。分析では、通常、デバッガー (デフォルトでは {{man|1|gdb}}) を使用してバックトレースを検査します。 |
||
+ | |||
+ | # coredumpctl debug ''match'' |
||
+ | |||
+ | ''gdb'' が開始されたら、{{ic|bt}} コマンドを使用してバックトレースを出力します。 |
||
+ | |||
+ | (gdb) bt |
||
+ | 多くの場合、出力には、欠落しているデバッグ シンボルのプレースホルダーとして疑問符が含まれます。トレースの取得方法については、[[デバッグ/トレースを取得]] を参照してください。 |
||
− | {{ic|/var/lib/systemd/coredump/}} に保存されたコアダンプファイルは {{ic|systemd-tmpfiles --clean}} によって自動的にクリーンアップされます。これは {{ic|systemd-tmpfiles-clean.timer}} によって毎日実行されます。コアダンプは最低でも 3 日間持続するように設定されています。{{ic|systemd-tmpfiles --cat-config}} を参照してください。 |
||
== 参照 == |
== 参照 == |
2023年10月15日 (日) 15:02時点における最新版
コアダンプとは突然プロセスが終了したときのプロセスのアドレス空間 (メモリ) を記録するファイルです。コアダンプは終了時に自動的に生成されるだけでなく、(デバッガなどによって) 必要に応じて生成される場合もあります。コアダンプはプログラムのクラッシュに対する反応としてカーネルによって引き起こされ、(systemd-coredump などの) ヘルパープログラムに渡されて処理されます。コアダンプは普通のユーザーにとってはあまり意味をなしませんが、開発者がユーザーにコアダンプの提出を要求することがあります。問題を再現することが難しいような場合、クラッシュ時のプログラムの状態を検死する手段としてコアダンプは有用です。
目次
自動的なコアダンプの無効化
コアダンプの自動生成を無効化する理由としては以下のようなことが考えられます:
- パフォーマンス: メモリの消費が激しいプロセスのコアダンプを生成するとき、システムリソースが浪費され、メモリの消去が遅延します。
- ディスク容量: 圧縮されない場合、コアダンプはメモリの使用量と同じ分だけ、あるいはそれ以上のディスク容量を消費します。
- セキュリティ: コアダンプは基本的に root しか読みことができないものですが、クラッシュの後にディスクに書き込まれた機密情報 (パスワードや暗号鍵など) が含まれている可能性があります。
sysctl を使う
sysctl を使って kernel.core_pattern
を設定することでコアダンプを無効化できます。以下のファイルを作成してください:
/etc/sysctl.d/50-coredump.conf
kernel.core_pattern=/dev/null
設定を今すぐ適用するには、sysctl
を使用してください:
# sysctl -p /etc/sysctl.d/50-coredump.conf
systemd を使う
systemd はデフォルトで全てのプロセスのコアダンプを /var/lib/systemd/coredump
に生成します。/etc/systemd/coredump.conf.d/
ディレクトリに以下の内容で設定スニペットを作成することで生成しないようにすることが可能です。
(こちらを参照 coredump.conf(5) § DESCRIPTION, [1]):
/etc/systemd/coredump.conf.d/custom.conf
[Coredump] Storage=none ProcessSizeMax=0
それから systemd の設定をリロードしてください:
# systemctl daemon-reload
参照 systemd-coredump(8) § Disabling coredump processing
PAM limits を使う
PAM でログインしたユーザーの最大コアダンプサイズは limits.conf によって強制されます。これをゼロにすると、コアダンプが完全に無効になります。[2]
/etc/security/limits.conf
* hard core 0
ulimit を使う
コアダンプの上限容量は ulimit によって決まります。ulimit をゼロに設定すればコアダンプは完全に無効化されます [3]:
/etc/security/limits.conf
* hard core 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
という名前のコアダンプファイルが生成されています。
コアダンプの保存場所
kernel.core_pattern
sysctl は自動的にコアダンプの保存先を決定します。デフォルトでは、コアダンプは systemd-coredump に送信されます。これは /etc/systemd/coredump.conf
で設定できます。デフォルトでは、すべてのコアダンプは /var/lib/systemd/coredump
に保存され (Storage=external
のため)、zstd
で圧縮されます。(Compress=yes
の場合) さらに、ストレージのさまざまなサイズ制限を設定できます。
journal からコアダンプを取得するには、coredumpctl(1) を参照してください。
コアダンプの確認
coredumpctl を使用して、対応するダンプを見つけます。通常のユーザーは、プロセスのコアダンプを管理するための特別な権限がなくても coredumpctl を実行できることに注意してください。
# coredumpctl list
コアダンプファイルのクリーンアップ
/var/lib/systemd/coredump/
に保存されているコアダンプファイルは、systemd-tmpfiles --clean
によって自動的にクリーンアップされます。これは、systemd-tmpfiles-clean.timer
によって毎日トリガーされます。コアダンプは少なくとも 3 日間保持されるように設定されています。systemd-tmpfiles --cat-config
を参照してください。
コアダンプの分析
まず、関連するダンプを一意に特定する必要があります。これはPID
、実行ファイル名、実行ファイルへのパス、journalctl 述語を指定することで可能です (詳細は coredumpctl(1) と journalctl(1) を参照) コアダンプの詳細を見るには
# coredumpctl info match
クラッシュの原因を特定するのに役立つ "Signal" 行に注目してください。分析では、通常、デバッガー (デフォルトでは gdb(1)) を使用してバックトレースを検査します。
# coredumpctl debug match
gdb が開始されたら、bt
コマンドを使用してバックトレースを出力します。
(gdb) bt
多くの場合、出力には、欠落しているデバッグ シンボルのプレースホルダーとして疑問符が含まれます。トレースの取得方法については、デバッグ/トレースを取得 を参照してください。
参照
- american fuzzy lop - カーネルやプログラムのテストを自動化するツール
- Filesystem fuzzing - ファイルシステムのバグをテストする LWN の記事