Häufig gestellte Fragen zu Speicherabbildern

In diesem Artikel werden häufig gestellte Fragen zum Sammeln von Dumps in .NET beantwortet.

Warum funktioniert die Dumpsammlung unter Linux nicht?

Um die Dumpauflistung zu implementieren, spawnen .NET-Prozesse einen untergeordneten Prozess namens createdump. Dieser untergeordnete Prozess verwendet die Linux-API ptrace() und liest auch aus dem /proc-Dateisystem , um auf Thread- und Speicherdaten zuzugreifen, die in die Speicherabbilddatei geschrieben werden. Obwohl die API-Verwendung durch die Standardsicherheitseinstellungen in vielen Linux-Distros zulässig ist, verweigert manchmal eine weniger häufige Sicherheitskonfiguration den Zugriff. Möglicherweise sehen Sie die Ausgabe des createdump-Prozesses, die in der Konsole der Dumpanwendung ausgegeben wird, wie z. B.:

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

Ein Grund, warum der Zugriff verweigert werden kann, besteht darin, dass ein Sicherheits-Sandkasten den Aufruf mithilfe eines Seccomp BPF-Filters abfangen kann. Für Anwendungen, die in einem Container mit Open Container Initiative-Technologie ausgeführt werden, muss das seccomp Profil Anrufe zu ptrace zulassen. Beispielsweise verwendet Docker im Hintergrund containerd als Containerruntime. Beim Initialisieren gibt es ein Standard seccomp-Profil an, das nur zulässt ptrace , wenn der Containerhost eine Kernelversion höher als 4.8 aufweist oder wenn die CAP_SYS_PTRACE Funktion im Container angegeben wurde.

Wenn die Aufrufe nicht abgefangen werden, führt der Kernel eine Vielzahl integrierter Zugriffsprüfungen durch. Die Dokumente für ptrace() enthalten eine detaillierte Beschreibung am Ende mit dem Titel "Ptrace Access Mode Checking", die beschreibt, wie diese durchgeführt werden. Beim Zugriff auf das Dateisystem „/proc“ wird auch eine Variation der gleichen ptrace-Zugriffsmodusüberprüfung verwendet. Nachfolgend finden Sie eine gekürzte Zusammenfassung der durchgeführten Sicherheitsprüfungen und Orte, an denen der Zugriff verweigert werden kann:

• Entweder muss der Aufrufvorgang über dieselbe Benutzer-ID wie der Zielprozess verfügen, oder der aufrufende Prozess muss über CAP_SYS_PTRACE verfügen. Wenn keine dieser Elemente zutrifft, wird der Zugriff verweigert. Da die .NET-Laufzeit beim Starten von createdump nichts tut, um das Benutzerkonto zu ändern, sollten die Benutzer-IDs übereinstimmen, und dieser Schritt sollte erfolgreich sein.
• Wenn createdump nicht über CAP_SYS_PTRACE verfügt (was standardmäßig nicht der Fall ist), muss der Zielprozess, der gedumpt werden soll, als „dumpable“ gekennzeichnet werden. Standardmäßig sind die meisten Prozesse unter Linux dumpfähig, aber Sie können diese Einstellung ändern, indem Sie prctl() mit der Option PR_SET_DUMPABLE aufrufen. Wenn Sie einem Prozess Funktionen mithilfe des setcap-Tools hinzufügen, kann dies auch dazu führen, dass ein Prozess nicht mehr gedumpt werden kann. Eine ausführlichere Beschreibung der dumpfähigen Einstellung und zu deren Deaktivierung finden Sie in der Linux-Dokumentation.
• Alle aktivierten Linux-Sicherheitsmodule (LSMs) werden aufgezählt, und jeder von ihnen muss den Zugriff genehmigen. Wenn ein LSM den Zugriff verweigert, gibt es leider keinen einheitlichen Linux-Berichterstellungsmechanismus, um zu wissen, welcher verantwortlich ist. Stattdessen müssen Sie ermitteln, welche auf Ihrem System aktiviert sind, und dann jede einzelne Untersuchung durchführen. Sie können ermitteln, welche LSMs aktiv sind, indem Sie Folgendes ausführen: cat /sys/kernel/security/lsm Obwohl alle LSM verantwortlich sein könnten, sind Yama, SELinux und AppArmor häufig die relevanten.

AppArmor und SELinux verfügen über umfangreiche Konfigurations- und Berichterstellungsmechanismen. Wenn Sie also erfahren müssen, wie Sie damit arbeiten können, sollten Sie die eigene Dokumentation jedes Projekts anzeigen. Yama verfügt nur über eine einzelne Konfigurationseinstellung, die durch Ausführen angezeigt werden kann:

cat /proc/sys/kernel/yama/ptrace_scope

Dieser Befehl gibt eine Zahl aus, die die aktuelle Yama-Ptrace-Sicherheitsrichtlinie angibt.

• 0: Klassische ptrace-Berechtigungen.
• 1: Eingeschränkte ptrace.
• 2: Nur Anhänge durch Administratoren.
• 3: Kein Anfügen.

Yama sollte den Zugriff für createdump unter den Richtlinien 0 und 1 gewähren, es wird jedoch erwartet, dass der Zugriff unter den Richtlinien 2 und 3 verweigert wird. Richtlinie 3 verweigert immer den Zugriff, und Richtlinie 2 funktioniert nicht standardmäßig, da createdump normalerweise nicht über die Funktion CAP_SYS_PTRACE verfügt.

Warum erhalte ich nur Dumps unter Linux, wenn dotnet-dump oder mein Absturzprozess mit erhöhten Rechten ausgeführt wird?

Einige Linux-basierte Systeme sind mit Sicherheitsrichtlinien konfiguriert, die verlangen, dass Prozesse, die einen Speicherabzug sammeln, die Fähigkeit CAP_SYS_PTRACE besitzen. Normalerweise verfügen Prozesse nicht über diese Funktion, aber das Ausführen mit erhöhten Rechten ist eine Möglichkeit, sie zu aktivieren. Eine ausführliche beschreibung, wie sich Linux-Sicherheitsrichtlinien auf die Dumpsammlung auswirken, finden Sie unter "Warum tritt ein Dumpsammlungsfehler auf Linux auf?".

Warum kann ich bei Ausführung innerhalb eines Containers keine Speicherabbilder sammeln?

Für Anwendungen, die unter jeder Open Container Initiative-Technologie ausgeführt werden, muss das seccomp Profil Aufrufe von "ptrace()" zulassen. Beispielsweise verwendet Docker im Hintergrund containerd als Containerruntime. Beim Initialisieren der Laufzeit gibt es ein Standard seccomp-Profil an, das nur zulässt ptrace , wenn der Containerhost eine Kernelversion höher als 4.8 aufweist oder wenn die CAP_SYS_PTRACE Funktion angegeben wurde.

Eine ausführliche Beschreibung, wie sich Linux-Sicherheitsrichtlinien auf die Speicherabbildsammlung auswirken, finden Sie in der Frage „Warum schlägt die Speicherabbildsammlung unter Linux fehl?“.

Warum kann ich unter macOS keine Speicherabbilder sammeln?

Unter macOS erfordert die Verwendung von ptrace, dass der Host des Zielprozesses über die erforderlichen Berechtigungen verfügt. Informationen zu den mindest erforderlichen Berechtigungen finden Sie unter "Standardberechtigungen".

Warum kann ich keine Dumps unter Android oder iOS erfassen?

Die Dumpsammlung wird auf mobilen Plattformen (Android und iOS) nicht unterstützt. Diese Plattformen verwenden die Mono-Runtime, die die Speicherabbildgenerierung nicht unterstützt.

Wo kann ich mehr darüber erfahren, wie ich Dumps nutzen kann, um Probleme in meiner .NET-Anwendung zu diagnostizieren?

Hier sind einige zusätzliche Ressourcen:

• Debuggen von Linux-Dumps
• Debuggen eines Deadlocks in einer .NET-App

Wie kann ich „Es konnte keine kompatible Frameworkversion gefunden werden.“ lösen?

Unter Linux muss die DOTNET_ROOT Umgebungsvariable beim Festlegen auf den richtigen Ordner verweisen. Wenn es auf eine andere .NET-Version verweist, wird dotnet-dump den Fehler immer erzeugen. Wenn die DOTNET_ROOT Umgebungsvariable nicht festgelegt ist, wird ein anderer Fehler erzeugt ("Sie müssen .NET installieren, um diese Anwendung auszuführen").

In diesem Artikel werden häufig gestellte Fragen zum Sammeln von Dumps in .NET beantwortet.

Um die Dumpauflistung zu implementieren, spawnen .NET-Prozesse einen untergeordneten Prozess namens createdump. Dieser untergeordnete Prozess verwendet die Linux-API ptrace() und liest auch aus dem /proc-Dateisystem , um auf Thread- und Speicherdaten zuzugreifen, die in die Speicherabbilddatei geschrieben werden. Obwohl die API-Verwendung durch die Standardsicherheitseinstellungen in vielen Linux-Distros zulässig ist, verweigert manchmal eine weniger häufige Sicherheitskonfiguration den Zugriff. Möglicherweise sehen Sie die Ausgabe des createdump-Prozesses, die in der Konsole der Dumpanwendung ausgegeben wird, wie z. B.:

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

Ein Grund, warum der Zugriff verweigert werden kann, besteht darin, dass ein Sicherheits-Sandkasten den Aufruf mithilfe eines Seccomp BPF-Filters abfangen kann. Für Anwendungen, die in einem Container mit Open Container Initiative-Technologie ausgeführt werden, muss das seccomp Profil Anrufe zu ptrace zulassen. Beispielsweise verwendet Docker im Hintergrund containerd als Containerruntime. Beim Initialisieren gibt es ein Standard seccomp-Profil an, das nur zulässt ptrace , wenn der Containerhost eine Kernelversion höher als 4.8 aufweist oder wenn die CAP_SYS_PTRACE Funktion im Container angegeben wurde.

Wenn die Aufrufe nicht abgefangen werden, führt der Kernel eine Vielzahl integrierter Zugriffsprüfungen durch. Die Dokumente für ptrace() enthalten eine detaillierte Beschreibung am Ende mit dem Titel "Ptrace Access Mode Checking", die beschreibt, wie diese durchgeführt werden. Beim Zugriff auf das Dateisystem „/proc“ wird auch eine Variation der gleichen ptrace-Zugriffsmodusüberprüfung verwendet. Nachfolgend finden Sie eine gekürzte Zusammenfassung der durchgeführten Sicherheitsprüfungen und Orte, an denen der Zugriff verweigert werden kann:

• Entweder muss der Aufrufvorgang über dieselbe Benutzer-ID wie der Zielprozess verfügen, oder der aufrufende Prozess muss über CAP_SYS_PTRACE verfügen. Wenn keine dieser Elemente zutrifft, wird der Zugriff verweigert. Da die .NET-Laufzeit beim Starten von createdump nichts tut, um das Benutzerkonto zu ändern, sollten die Benutzer-IDs übereinstimmen, und dieser Schritt sollte erfolgreich sein.
• Wenn createdump nicht über CAP_SYS_PTRACE verfügt (was standardmäßig nicht der Fall ist), muss der Zielprozess, der gedumpt werden soll, als „dumpable“ gekennzeichnet werden. Standardmäßig sind die meisten Prozesse unter Linux dumpfähig, aber Sie können diese Einstellung ändern, indem Sie prctl() mit der Option PR_SET_DUMPABLE aufrufen. Wenn Sie einem Prozess Funktionen mithilfe des setcap-Tools hinzufügen, kann dies auch dazu führen, dass ein Prozess nicht mehr gedumpt werden kann. Eine ausführlichere Beschreibung der dumpfähigen Einstellung und zu deren Deaktivierung finden Sie in der Linux-Dokumentation.
• Alle aktivierten Linux-Sicherheitsmodule (LSMs) werden aufgezählt, und jeder von ihnen muss den Zugriff genehmigen. Wenn ein LSM den Zugriff verweigert, gibt es leider keinen einheitlichen Linux-Berichterstellungsmechanismus, um zu wissen, welcher verantwortlich ist. Stattdessen müssen Sie ermitteln, welche auf Ihrem System aktiviert sind, und dann jede einzelne Untersuchung durchführen. Sie können ermitteln, welche LSMs aktiv sind, indem Sie Folgendes ausführen: cat /sys/kernel/security/lsm Obwohl alle LSM verantwortlich sein könnten, sind Yama, SELinux und AppArmor häufig die relevanten.

AppArmor und SELinux verfügen über umfangreiche Konfigurations- und Berichterstellungsmechanismen. Wenn Sie also erfahren müssen, wie Sie damit arbeiten können, sollten Sie die eigene Dokumentation jedes Projekts anzeigen. Yama verfügt nur über eine einzelne Konfigurationseinstellung, die durch Ausführen angezeigt werden kann:

cat /proc/sys/kernel/yama/ptrace_scope

Dieser Befehl gibt eine Zahl aus, die die aktuelle Yama-Ptrace-Sicherheitsrichtlinie angibt.

• 0: Klassische ptrace-Berechtigungen.
• 1: Eingeschränkte ptrace.
• 2: Nur Anhänge durch Administratoren.
• 3: Kein Anfügen.

Yama sollte den Zugriff für createdump unter den Richtlinien 0 und 1 gewähren, es wird jedoch erwartet, dass der Zugriff unter den Richtlinien 2 und 3 verweigert wird. Richtlinie 3 verweigert immer den Zugriff, und Richtlinie 2 funktioniert nicht standardmäßig, da createdump normalerweise nicht über die Funktion CAP_SYS_PTRACE verfügt.

Einige Linux-basierte Systeme sind mit Sicherheitsrichtlinien konfiguriert, die verlangen, dass Prozesse, die einen Speicherabzug sammeln, die Fähigkeit CAP_SYS_PTRACE besitzen. Normalerweise verfügen Prozesse nicht über diese Funktion, aber das Ausführen mit erhöhten Rechten ist eine Möglichkeit, sie zu aktivieren. Eine ausführliche beschreibung, wie sich Linux-Sicherheitsrichtlinien auf die Dumpsammlung auswirken, finden Sie unter "Warum tritt ein Dumpsammlungsfehler auf Linux auf?".

Für Anwendungen, die unter jeder Open Container Initiative-Technologie ausgeführt werden, muss das seccomp Profil Aufrufe von "ptrace()" zulassen. Beispielsweise verwendet Docker im Hintergrund containerd als Containerruntime. Beim Initialisieren der Laufzeit gibt es ein Standard seccomp-Profil an, das nur zulässt ptrace , wenn der Containerhost eine Kernelversion höher als 4.8 aufweist oder wenn die CAP_SYS_PTRACE Funktion angegeben wurde.

Eine ausführliche Beschreibung, wie sich Linux-Sicherheitsrichtlinien auf die Speicherabbildsammlung auswirken, finden Sie in der Frage „Warum schlägt die Speicherabbildsammlung unter Linux fehl?“.

Unter macOS erfordert die Verwendung von ptrace, dass der Host des Zielprozesses über die erforderlichen Berechtigungen verfügt. Informationen zu den mindest erforderlichen Berechtigungen finden Sie unter "Standardberechtigungen".

Die Dumpsammlung wird auf mobilen Plattformen (Android und iOS) nicht unterstützt. Diese Plattformen verwenden die Mono-Runtime, die die Speicherabbildgenerierung nicht unterstützt.

Hier sind einige zusätzliche Ressourcen:

• Debuggen von Linux-Dumps
• Debuggen eines Deadlocks in einer .NET-App

Unter Linux muss die DOTNET_ROOT Umgebungsvariable beim Festlegen auf den richtigen Ordner verweisen. Wenn es auf eine andere .NET-Version verweist, wird dotnet-dump den Fehler immer erzeugen. Wenn die DOTNET_ROOT Umgebungsvariable nicht festgelegt ist, wird ein anderer Fehler erzeugt ("Sie müssen .NET installieren, um diese Anwendung auszuführen").