Häufig gestellte Fragen zu Dumps

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, der auf der Konsole der Anwendung geschrieben wurde, die abgebildet wird, 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 zulassen ptrace. Verwendet z. B Docker . containert unter der Haube als Containerlaufzeit. 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 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 (standardmäßig nicht), muss der abzubildete Zielprozess 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 abbildbar ist. Eine ausführlichere Beschreibung der speicherabbildbaren 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-Sicherheitsrichtlinie angibt:

• 0: Klassische Zugriffsberechtigungen.
• 1: Eingeschränkter Vertrahen.
• 2: Nur Administrator anfügen.
• 3: Kein Anfügen.

Yama sollte den Zugriff für createdump unter den Richtlinien 0 und 1 gewähren, aber 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 alle Prozesse erfordern, die ein Dump sammeln, um die Funktion CAP_SYS_PTRACE zu haben. Normalerweise verfügen Prozesse nicht über diese Funktion, aber das Ausführen von 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 Dumps nicht erfassen, wenn sie in einem Container ausgeführt werden?

Für Anwendungen, die unter jeder Open Container Initiative-Technologie ausgeführt werden, muss das seccomp Profil Aufrufe von "ptrace()" zulassen. Verwendet z. B Docker . containert unter der Haube als Containerlaufzeit. 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 Dumpsammlung auswirken, finden Sie in der Frage "Warum ist dump collection fail on Linux?".

Warum kann ich Keine Dumps unter macOS sammeln?

Unter macOS muss der ptrace Host des Zielprozesses ordnungsgemäß berechtigt sein. Informationen zu den mindest erforderlichen Berechtigungen finden Sie unter "Standardberechtigungen".

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 war nicht möglich, kompatible Framework-Version zu finden"

Unter Linux muss die DOTNET_ROOT Umgebungsvariable beim Festlegen auf den richtigen Ordner verweisen. Wenn sie auf eine andere .NET-Version verweist, dotnet-dump wird dieser Fehler immer erzeugt. 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, der auf der Konsole der Anwendung geschrieben wurde, die abgebildet wird, 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 zulassen ptrace. Verwendet z. B Docker . containert unter der Haube als Containerlaufzeit. 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 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 (standardmäßig nicht), muss der abzubildete Zielprozess 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 abbildbar ist. Eine ausführlichere Beschreibung der speicherabbildbaren 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-Sicherheitsrichtlinie angibt:

• 0: Klassische Zugriffsberechtigungen.
• 1: Eingeschränkter Vertrahen.
• 2: Nur Administrator anfügen.
• 3: Kein Anfügen.

Yama sollte den Zugriff für createdump unter den Richtlinien 0 und 1 gewähren, aber 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 alle Prozesse erfordern, die ein Dump sammeln, um die Funktion CAP_SYS_PTRACE zu haben. Normalerweise verfügen Prozesse nicht über diese Funktion, aber das Ausführen von 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. Verwendet z. B Docker . containert unter der Haube als Containerlaufzeit. 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 Dumpsammlung auswirken, finden Sie in der Frage "Warum ist dump collection fail on Linux?".

Unter macOS muss der ptrace Host des Zielprozesses ordnungsgemäß berechtigt sein. Informationen zu den mindest erforderlichen Berechtigungen finden Sie unter "Standardberechtigungen".

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 sie auf eine andere .NET-Version verweist, dotnet-dump wird dieser Fehler immer erzeugt. Wenn die DOTNET_ROOT Umgebungsvariable nicht festgelegt ist, wird ein anderer Fehler erzeugt ("Sie müssen .NET installieren, um diese Anwendung auszuführen").