Vanliga frågor och svar om dumpar

För att implementera dumpinsamling skapar .NET-processer en underordnad process med namnet createdump. Den här underordnade processen använder Linux API ptrace() och läser även från filsystemet /proc för att komma åt tråd- och minnesdata som skrivs till dumpfilen. Även om API-användningen tillåts av standardsäkerhetsinställningarna på många Linux-distributioner, kommer ibland en mindre vanlig säkerhetskonfiguration att neka åtkomst. Du kan se utdata från createump-processen som skrivits på konsolen för programmet som dumpas, till exempel:

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

En orsak till att åtkomst kan nekas är om en säkerhetssandbox fångar upp anropet med hjälp av ett SECCOMP BPF-filter. För program som körs i en container med hjälp av Open Container Initiative-teknik måste profilen seccomp tillåta anrop till ptrace. Använder till exempel Dockercontainer under huven som en containerkörning. När du initierar anger den en standardprofil för seccomp som endast tillåter ptrace om containervärden har en kernelversion som är högre än 4.8 eller om CAP_SYS_PTRACE funktionen har angetts i containern.

Om anropen inte fångas upp gör kerneln en mängd olika inbyggda åtkomstkontroller. Dokumenten för ptrace() innehåller en detaljerad beskrivning nära slutet, med titeln "Kontroll av ptrace-åtkomstläge", som beskriver hur dessa görs. Vid åtkomst till filsystemet /proc används också en variant av samma kontroll av ptrace-åtkomstläge. Följande är en förkortad sammanfattning av de säkerhetskontroller som utförts och platser där åtkomst kan nekas:

• Antingen måste anropsprocessen ha samma användar-ID som målprocessen, eller så måste samtalsprocessen ha CAP_SYS_PTRACE. Om inget av dessa är sant nekas åtkomst. Eftersom .NET-körningen inte gör något för att ändra användarkontot när du startar createdump, bör användar-ID:erna matcha och det här steget bör lyckas.
• Om createdump inte har CAP_SYS_PTRACE (det gör det inte som standard) måste målprocessen som dumpas markeras som "dumpable". Som standard är de flesta processer i Linux dumpbara, men du kan ändra den här inställningen genom att anropa prctl() med alternativet PR_SET_DUMPABLE. Om du lägger till funktioner i en process med setcap-verktyget kan det också leda till att en process slutar att vara dumpbar. En mer detaljerad beskrivning av den dumpbara inställningen och vad som gör att den inaktiveras finns i Linux-dokumentationen.
• Alla aktiverade Linux-säkerhetsmoduler (LSM) räknas upp och var och en av dem måste godkänna åtkomsten. Om en LSM nekar åtkomst finns det tyvärr ingen enhetlig Linux-rapporteringsmekanism för att veta vilken som är ansvarig. I stället måste du ta reda på vilka som är aktiverade i systemet och sedan undersöka var och en individuellt. Du kan avgöra vilka LSM:er som är aktiva genom att köra: cat /sys/kernel/security/lsm. Även om alla LSM:er kan vara ansvariga är Yama, SELinux och AppArmor ofta relevanta.

Både AppArmor och SELinux har omfattande konfigurations- och rapporteringsmekanismer, så om du behöver lära dig hur du arbetar med dem är det bäst att visa varje projekts egen dokumentation. Yama har bara en enda konfigurationsinställning som kan visas genom att köra:

cat /proc/sys/kernel/yama/ptrace_scope

Det här kommandot matar ut ett tal som anger den aktuella säkerhetsprincipen för Yama ptrace:

• 0: Klassiska ptrace-behörigheter.
• 1: Begränsad ptrace.
• 2: Bifoga endast administratör.
• 3: Ingen bifoga.

Yama bör bevilja åtkomst för createdump enligt principerna 0 och 1, men förvänta dig att åtkomst nekas enligt principerna 2 och 3. Princip 3 nekar alltid åtkomst och princip 2 fungerar inte som standard eftersom createdump normalt inte har funktionen CAP_SYS_PTRACE.

Vissa Linux-baserade system är konfigurerade med säkerhetsprinciper som kräver alla processer som samlar in en dump för att ha funktionen CAP_SYS_PTRACE. Normalt har processer inte den här funktionen, men att köra förhöjd är ett sätt att aktivera den. En mer fullständig beskrivning av hur Linux-säkerhetsprinciper påverkar dumpinsamling finns i "Varför misslyckas dumpsamlingen i Linux?".

För program som körs under någon Open Container Initiative-teknik måste profilen seccomp tillåta anrop till ptrace(). Använder till exempel Dockercontainer under huven som en containerkörning. När körningen initieras anger den en standardprofil för seccomp som endast tillåter ptrace om containervärden har en kernelversion som är högre än 4,8 eller om CAP_SYS_PTRACE funktionen har angetts.

En mer fullständig beskrivning av hur Linux-säkerhetsprinciper påverkar dumpinsamlingen finns i frågan "Varför misslyckas dumpsamlingen i Linux?".

För macOS kräver användningen av ptrace värden för målprocessen att vara korrekt berättigad. Information om de minsta nödvändiga rättigheterna finns i Standardrättigheter.

Här är några ytterligare resurser:

• Felsöka Linux-dumpar
• Felsöka ett dödläge i en .NET-app

I Linux DOTNET_ROOT måste miljövariabeln peka på rätt mapp när den anges. När den pekar på en annan .NET-version skapar dotnet-dump du alltid det här felet. DOTNET_ROOT När miljövariabeln inte har angetts genereras ett annat fel ("Du måste installera .NET för att köra det här programmet").