ダンプに関する FAQ

ダンプ コレクションを実装するために、.NET プロセスは createdump という子プロセスを生成します。 この子プロセスは、Linux API ptrace() を使用し、/proc ファイルシステムから読み取って、ダンプ ファイルに書き込まれるスレッドおよびメモリ データにアクセスします。 API の使用は、多くの Linux ディストリビューションの既定のセキュリティ設定で許可されますが、あまり一般的でないセキュリティ構成ではアクセスが拒否される場合があります。 アプリケーションのコンソールに書き込まれた createdump プロセスからの出力がダンプされている場合があります。次に例を示します。

[createdump] The process or container does not have permissions or access: open(/proc/1234/mem) FAILED Permission denied (13)

アクセスが拒否される理由の 1 つは、セキュリティ サンドボックスが seccomp BPF フィルターを使用して呼び出しをインターセプトした場合です。 Open Container Initiative テクノロジを使用してコンテナーで実行されているアプリケーションの場合、seccomp プロファイルでは、ptraceの呼び出しを許可する必要があります。 たとえば、Docker はコンテナー ランタイムとして内部 コンテナー化された を使用します。 初期化時に、コンテナー ホストのカーネル バージョンが 4.8 より大きい場合、またはコンテナーで CAP_SYS_PTRACE 機能が指定されている場合にのみ、ptrace を許可する既定の seccomp プロファイル を指定します。

呼び出しがインターセプトされない場合、カーネルはさまざまな組み込みアクセス チェックを実行します。 ptrace() のドキュメントには、"Ptrace アクセス モード のチェック" というタイトルの末尾付近の詳細な説明が含まれています。この方法について説明します。 /proc ファイルシステムにアクセスすると、同じ ptrace アクセス モード チェックのバリエーションも使用されます。 以下は、実行されたセキュリティ チェックと、アクセスが拒否される可能性がある場所の要約です。

• 呼び出し元プロセスがターゲット プロセスと同じユーザー ID を持っているか、呼び出し元プロセスがCAP_SYS_PTRACEする必要があります。 これらのいずれかが当てはまらない場合、アクセスは拒否されます。 .NET ランタイムは createdump の起動時にユーザー アカウントを変更するために何も行わないので、ユーザー ID は一致する必要があり、この手順は成功するはずです。
• createdump にCAP_SYS_PTRACEがない場合 (既定では存在しません)、ダンプされるターゲット プロセスを "dumpable" とマークする必要があります。 既定では、Linux 上のほとんどのプロセスはダンプ可能ですが、この設定を変更するには、PR_SET_DUMPABLE オプション prctl() を呼び出します。 setcap ツールを使用してプロセスに機能を追加すると、プロセスがダンプ可能でなくなる可能性もあります。 ダンプ可能な設定とその無効の原因の詳細については、Linux ドキュメント を参照してください。
• 有効になっているすべての Linux セキュリティ モジュール (LSM) が列挙され、各モジュールがアクセスを承認する必要があります。 残念ながら、LSM がアクセスを拒否した場合、どちらが原因かを知る統一された Linux レポート メカニズムはありません。 代わりに、システムで有効になっているものを特定し、それぞれを個別に調査する必要があります。 アクティブな LSM は、cat /sys/kernel/security/lsmを実行して判断できます。 どの LSM も責任を負う可能性がありますが、Yama、SELinux、AppArmor は、多くの場合、関連します。

AppArmor と SELinux の両方に豊富な構成とレポートメカニズムがあるため、それらを操作する方法を学習する必要がある場合は、各プロジェクトの独自のドキュメントを表示することをお勧めします。 山には構成設定が 1 つだけあり、次を実行して表示できます。

cat /proc/sys/kernel/yama/ptrace_scope

このコマンドは、現在のYama ptraceセキュリティポリシーを示す番号を出力します。

• 0: 従来の ptrace アクセス許可。
• 1: 制限付き ptrace。
• 2: 管理者専用のアタッチ。
• 3: アタッチなし。

Yama はポリシー 0 とポリシー 1 で createdump へのアクセスを許可する必要がありますが、ポリシー 2 と 3 ではアクセスが拒否されることを想定しています。 ポリシー 3 では常にアクセスが拒否され、createdump には通常、CAP_SYS_PTRACE機能がないため、ポリシー 2 は既定では機能しません。

Linux ベースのシステムの中には、ダンプを収集するプロセスがCAP_SYS_PTRACE機能を備える必要があるセキュリティ ポリシーが構成されているものもあります。 通常、プロセスにはこの機能はありませんが、管理者特権で実行することは、それを有効にする 1 つの方法です。 Linux セキュリティ ポリシーがダンプ収集に与える影響の詳細については、「Linux でダンプ収集が失敗する理由」を参照してください。

Open Container Initiative テクノロジで実行されているアプリケーションの場合、seccomp プロファイルは ptrace() 呼び出しを許可する必要があります。 たとえば、Docker はコンテナー ランタイムとして内部 コンテナー化された を使用します。 ランタイムを初期化するときに、コンテナー ホストのカーネル バージョンが 4.8 より大きい場合、または CAP_SYS_PTRACE 機能が指定されている場合にのみ、ptrace を許可する既定の seccomp プロファイル を指定します。

Linux セキュリティ ポリシーがダンプ収集に与える影響の詳細については、「Linux でダンプ収集が失敗する理由」という質問を参照してください。

macOS では、ptrace を使用するには、ターゲット プロセスのホストに適切な資格が必要です。 最低限必要な権利の詳細については、「既定の権利を参照してください。

その他のリソースを次に示します。

• Linux ダンプ をデバッグする
• .NET アプリ でデッドロックをデバッグする

Linux では、DOTNET_ROOT 環境変数は、設定時に正しいフォルダーを指す必要があります。 別の .NET バージョンを指す場合、dotnet-dump は常にこのエラーを生成します。 DOTNET_ROOT 環境変数が設定されていない場合は、別のエラーが生成されます ("このアプリケーションを実行するには.NET をインストールする必要があります")。