すべてのシステムは、その主な目標を達成するためにプロセスを実行する必 しかし、時には物事がうまくいかず、プロセスがクラッシュすることがあります。 システムの構成に応じて、コアダンプが作成されます。 つまり、クラッシュしたプロセスのメモリスナップショットが格納されます。 コアという用語は、実際には古いシステムからの古い磁気コアメモリを指します。 このタイプのメモリはもはや使用されていませんが、Linuxシステムではまだこの用語を使用しています。 歴史のために十分な、のは、適切にコアダンプを処理するために私たちのLinuxシステムを設定してみましょう。
目次
Linuxとコアダンプ
ほとんどのLinuxシステムでは、デフォルトでコアダンプが有効になっています。 いつものように、ここで作るためのトレードオフがあります。 一方では、安定性とトラブルシューティングを向上させるためのデータを収集したいと考えています。 一方、デバッグデータを制限し、機密データが漏洩しないようにしたいと考えています。
最初のオプションは、開発者のワークステーションのように、不安定なプログラムを調査する必要があるマシンに適しています。 第二のオプションは、機密データを格納または処理する本番システムに適しています。
コアダンプを無効にする
Linuxでは、すべてのシステムでデフォルトでコアダンプを無効にするのが理にかなっています。 これは、ファイルがディスク領域を占有し、機密データが含まれている可能性があるためです。 したがって、トラブルシューティングの目的でコアダンプが必要ない場合は、それらを無効にすることは安全なオプ
オプション1:設定ファイルを介したulimit
コアダンプを無効にするには、ulimitの値を設定する必要があります。 これは/etc/security/limitsを介して行われます。confファイルといくつかのシェル固有の制限を定義します。
知っておくと良いことは、ソフトとハードの制限があるということです。 ハードリミットは決して上書きできないものですが、ソフトリミットは特定のユーザーにのみ適用できます。 どのプロセスもコアダンプを作成できないようにしたい場合は、両方をゼロに設定することができます。 ブール値（0=False、1=True）のように見えるかもしれませんが、実際には許可されたサイズを示します。
* ソフトコア0
*ハードコア0
アスタリスク記号は、すべてのユーザーに適用されることを意味します。 2番目の列は、ハード制限またはソフト制限を使用するかどうかを示し、その後に設定と値を示す列が続きます。Ulimitの値は、/etc/profileまたは/etc/profile内のカスタムファイルで設定することもできます。ulimitの値は、/etc/profileまたは/etc/profile内のカスタムファイルで設定することもできまdディレクトリ。 後者は、それが利用可能である場合に好ましい。 たとえば、/という名前のファイルを作成することによetc/profile.d/disable-coredumps.sh.
echo”ulimit-c0>/dev/null2>&1″ > /etc/プロフィール.d/disable-coredumps.sh
このコマンドは、新しいファイルに設定を追加し、ソフトとハードの両方の制限をゼロに設定します。 各ユーザーはログイン時にこの値を取得します。
ulimit設定のほかに、考慮すべきカーネル設定もあります。 そのため、オプションの1つを選択することが最初のステップです。
オプション3:systemd経由で無効にする
systemdとsystemd-coredumpサービスを使用する場合は、coredumpを変更します。confファイル。 ほとんどの場合、このファイルは/usr/lib/sysctlにあります。d/50-コアダンプ。コンフ… Systemdには一連のファイルがあるので、次のような他のファイルをチェックするようにしてください:
ストレージ設定を’none’に設定します。 次に、最大サイズをゼロに制限するようにProcessSizeMaxを構成します。
ストレージ=なし
ProcessSizeMax=0
通常はsystemd設定をリロードするだけで十分です。
systemctl daemon-reload
それでもコアダンプが作成される場合は、システムを再起動します。
setuidプロセスを無効にするメモリのダンプ
昇格された権限(またはsetuidビット)を持つプロセスは、他の設定によっては、まだコアダンプを実行できる これらのプロセスは通常、より多くのアクセス権を持っているので、メモリ内のより機密性の高いデータセグメントを含む可能性があります。 だから、これを変更する時間も。 この動作は、sysctlキーで変更するか、/procファイルシステムを介して直接変更できます。 永続的な設定では、通常、sysctlコマンドと構成が使用されます。 設定は’key’と呼ばれ、それに関連する値が添付されています（キーと値のペアとも呼ばれます）。
ダンプするsetuidビットでプログラムを無効にするには、fsを設定します。suid_dumpableをゼロにします。
echo "fs.suid_dumpable=0" >> /etc/sysctl.conf
変更を有効にするには、sysctl設定を-pフラグでリロードします。
sysctl -p
永久的な変更を行わずにテストしたいだけですか？ sysctl -wの後にkey=valueを使用します。
ヒント:sysctlを使用すると、システムを調整することができ、Linuxカーネルを強化する良い方法です。
コアダンプを有効にする
コアダンプを許可する主な理由は、トラブルシューティングの目的です。 プロセスのダンプされたメモリは、通常、より経験豊富な開発者が問題をデバッグするために使用することができます。 ソフトウェアベンダーは、コアダンプを有効にするように求めることができます。 通常、プロセスが最初にクラッシュした理由を発見し、それを引き起こした関連ルーチンを見つける。
Linuxでコアダンプを有効にすることは、いくつかの具体的な詳細を設定する必要があることを除いて、それらを無効にすることに似ています。 たとえば、特定のプログラムの詳細のみが必要な場合は、ソフト制限を使用できます。 これは、ソフトリミットであることを示す-Sを使用して行われます。 -cはコアダンプのサイズを示す。
ulimit -S -c 0
次のステップは、’my-program-to-troubleshoot’のみがコアダンプを作成できるようにすることです。
ulimit -S -c unlimited my-program-to-troubleshoot
すべてのプロセスがコアダンプを使用できるようにするには、上記の行をプログラムなしで使用するか、/etc/security/limitsにシステム制限を設定します。conf
* soft core unlimited
Setuidビットが設定されているバイナリ
のトラブルシューティングsetuidバイナリは、root権限で実行できます。 この特別なタイプのアクセスは、可能な限り制限する必要があります。 また、コアダンプを作成するには、適切に構成する必要があります。 これはsysctl fsで行われます。suid_dumpableキー。
- 0 – 無効
- 1–有効
- 2–制限付き有効
だから、setuidビットが設定されているプログラムのトラブルシューティングをしたい場合は、fsを一時的に変更することができます。suid_dumpableを1または2に設定します。 これにより、コアダンプはrootユーザーのみが読み取り可能になるため、2に設定することをお勧めします。 これは、機密データを持つシステムのための良い代替手段です。 このオプションを1に設定する方が、個人開発システムに適しています。
通常のダンプファイルを作成する
Linuxシステムの大きな謎の一つは、コアダンプがどこにあるかです。 Linuxには、コアダンプをキャプチャするためのトリックがあります。 この特定の設定はsysctlカーネルを介して行われます。または/proc/sys/kernel/core_patternを設定します。 ほとんどのシステムでは、プログラムが生成されたデータを処理する必要があることを示すために、この設定にパイプ(|)があります。 あなたのコアダンプがどこに行くのか疑問に思ったら、パイプに従ってください！
Ubuntuシステム上のコアダンプは、通常、Apportしようとしています。 Red Hatベースのシステムでは、自動バグ報告ツール(ABRT)にリダイレクトされることがあります。
“core”をそのファイルにエコーするか、sysctlユーティリティを使用して、この設定を一時的に変更することができます。
sysctl -w kernel.core_pattern=core
重要な注意点は、この変更では十分ではない可能性があることです。 それはあなたのfsにも依存します。suid_dumpable設定。 その場合は、カーネルロガーに警告が記録されます。
Sep06 15:51:18カーネルの強化:安全でないcore_patternをsuid_dumpable=2で使用しました。 パイプハンドラまたは完全修飾コアダンプパスが必要です。
必要に応じて、core_patternをフルパスに設定し、必要に応じて、誰が実行していたか、PIDなどを定義する変数を使用します。
sysctl-wカーネル。core_pattern=/var/crash/core.%u.%e.%p
この例では、ダンプにはユーザー id、プログラム名、およびプロセスidが含まれます。
Systemdコアダンプ
最新のLinuxディストリビューションを使用する場合、systemdが有効になっている可能性が最も高いでしょう。 /Etc/sysctlを介して設定を上書きする必要がある場合があります。d/50-コアダンプ。confとどのように、どこであなたのコアダンプを格納する定義します。
systemd-coredump
カーネルを使用します。core_patternはsystemd-coredumpユーティリティを使用するように定義することができます。 コアダンプが格納されるデフォルトのパスは、/var/lib/systemd/coredumpにあります。
設定のテスト
他のほとんどのチュートリアルでは、設定する設定を提供しています。 しかし、どのように物事が期待どおりに動作することを知っているだろうか？ あなたはそれをテストする必要があります！
コアダンプを作成する
オプション1:不安定なプログラムを作成する
簡単なプログラムを作成しましょう。 その主な目的は、実行時にクラッシュし、必要に応じてコアダンプを作成することです。 システムにgccをインストールし、ファイルクラッシュを作成します。ホームディレクトリ内のc。
int main(){ return 1/0;}
このプログラムはmain関数を起動し、整数値（数値）を返します。 ただし、1をゼロで除算していますが、これは許可されておらず、クラッシュします。 次のステップは、私たちの小さなバギープログラムをコンパイルしています。
私たちの不安定な小さなプログラム
コンパイラでさえ、私たちのプログラムに深刻な問題が含まれていることを示し、警告を表示します。 今度はそれを実行して、これが事実であるかどうかを見てみましょう。
素敵なクラッシュ！
この単一行から、実際にいくつかのことを学ぶことができます。 まず第一に、それは例外で終了し、特に浮動小数点を参照します。 これはプログラムの10進数形式なので、数学をしている間に何かが起こったことを示している可能性があります。 もう一つの結論は、最後に（core dumped）が追加されたためにコアがダンプされるということです。 コアダンプが無効になっている場合、これは表示されません。
素晴らしい、だから、上記のこのクラッシュで、我々は今、ダンプされたファイルを持っていますよね？ 正確には違う あなたのLinuxディストリビューションによっては、見た目ほど単純ではないかもしれません。 各ディストリビューションは、コアダンプとデフォルト設定とは異なる処理を行います。 最近のLinuxディストリビューションでもsystemdを使用しており、ルールも少し変更されています。 設定によっては、コアダンプを検索する必要がある場合があります。 ここでは、すべてが正しく構成されていることを確認するためのヒントをいくつか紹介します。
オプション2:実行中のプロセスを強制終了
テストプログラムを使用する代わりに、既存のプロセスを終了することもできます。 これはsigsegvを使用して行われます。SIGSEGVはsegmentation violationの略で、segmentation faultとも呼ばれます。
kill -s SIGSEGV PID
PIDを”$ $”に置き換えると、現在のプログラム（おそらくシェル）がクラッシュします。 科学のためのすべて、右？
オプション3:gdbの使用
開発者デバッグツールgdbがインストールされている場合は、プロセスID(PID)を使用して選択したプロセスにアタッチします。
gdb -p 1234
次に、gdbプロンプトが表示されたら、generate-core-file命令を呼び出してコアダンプを生成します。 このコマンドを使用すると、出力が返されます。
corefileコアを保存しました。1234
チェックulimit設定
ulimit設定は、プログラムがクラッシュしたときに何が起こるかを定義します。 したがって、rootと通常の非特権ユーザーの両方で、最初にこれを確認することは安全です。
コアダンプのハードリミットを確認する:
ulimit -H -c
ソフトリミットもチェック:
ulimit -S -c
コアパターンのチェック
/procファイルシステムを使用して値を収集し、テスト中に一時的に変更します。 Sysctlを使用する場合は、カーネルを照会します。core_patternキー。
cat /proc/sys/kernel/core_pattern
次のようなものが表示される場合があります:
|/usr/share/apport/apport %p %s %c %P
この場合、クラッシュはapportユーティリティにパイプされます。 これは、クラッシュがApportによって分析されることを意味します。 通常、クラッシュは/var/crashにありますが、他のLinuxディストリビューションでは/var/spoolまたは/var/lib/systemd/coredumpにもあります。
ジャーナルをチェック(systemd)
私たちのケースではjournalctl私たちのクラッシュを示しているので、それが始まりです。
これらの設定をすべて確認した後、素敵なコアダンプを作成できるはずです。
結論
コアダンプはトラブルシューティングに役立ちますが、機密データが漏洩する災害に役立ちます。 可能であればコアダンプを無効にし、本当に必要なときにのみ有効にします。 そのような場合、ファイルが安全に保存されているかどうかを確認するので、通常のユーザーはデータを見ることができません。 また、どのような選択を行ったかとは無関係に、設定が期待どおりに機能するかどうかを常にテストしてください。