varje system behöver köra processer för att uppfylla sitt primära mål. Men ibland går saker fel och en process kan krascha. Beroende på systemets konfiguration skapas en kärndump. Med andra ord lagras en minnesbild av den kraschade processen. Termen kärna hänvisar faktiskt till det gamla magnetiska kärnminnet från äldre system. Även om denna typ av minne inte längre används, använder vi fortfarande denna term på Linux-system. Tillräckligt för historia, låt oss konfigurera vårt Linux-system för att hantera kärndumpar korrekt.
Innehållsförteckning
Linux och core dumpar
de flesta Linux-system har core dumpar aktiverat som standard. Som alltid finns det en avvägning att göra här. Å ena sidan vill vi samla in data för förbättrad stabilitet och felsökning. Å andra sidan vill vi begränsa felsökningsdata och undvika att läcka känsliga data.
det första alternativet är bra för maskiner där instabila program måste undersökas, som en utvecklares arbetsstation. Det andra alternativet är bättre lämpat för produktionssystem som lagrar eller behandlar känsliga data.
inaktivera kärndumpar
det är vettigt att inaktivera alla kärndumpar på Linux som standard för alla dina system. Detta beror på att filerna tar upp diskutrymme och kan innehålla känsliga data. Så om du inte behöver kärndumparna för felsökningsändamål är det ett säkert alternativ att inaktivera dem.
alternativ 1: ulimit via konfigurationsfilen
för att inaktivera kärndumpar måste vi ställa in ett ulimit värde. Detta görs via / etc/säkerhet / gränser.conf-fil och definierar vissa skalspecifika begränsningar.
bra att veta är att det finns mjuka och hårda gränser. En hård gräns är något som aldrig kan åsidosättas, medan en mjuk gräns endast kan tillämpas för specifika användare. Om vi vill se till att ingen process kan skapa en kärndump, kan vi ställa dem båda till noll. Även om det kan se ut som en boolesk (0 = falsk, 1 = sann), indikerar den faktiskt den tillåtna storleken.
* mjuk kärna 0
* hård kärna 0
asterisktecknet betyder att det gäller alla användare. Den andra kolumnen anger om vi vill använda en hård eller mjuk gräns, följt av kolumnerna som anger inställningen och värdet.
alternativ 2: Konfigurera ulimit via profil
värdena för ulimit kan också ställas in via /etc/profile eller en anpassad fil i /etc/profile.d katalog. Det senare föredras när det är tillgängligt. Till exempel genom att skapa en fil med namnet /etc/profile.d/disable-coredumps.sh.
echo ”ulimit-c 0 > /dev /null 2>&1” > /etc / profil.d / inaktivera-coredumps.sh
detta kommando lägger till inställningen i en ny fil och ställer in både mjuk och hård gräns till noll. Varje användare får detta värde när de loggar in.
förutom ulimit-inställningar finns det också kärninställningar att överväga. Så att välja ett av alternativen är det första steget.
alternativ 3: Inaktivera via systemd
när du använder systemd och systemd-coredump-tjänsten, ändra coredump.conf-fil. Den här filen finns troligen på /usr/lib / sysctl.d / 50-coredump.conf. Eftersom systemd har en uppsättning filer, se till att kontrollera de andra som:
Ställ in Lagringsinställningen på ’none’. Konfigurera sedan ProcessSizeMax för att begränsa den maximala storleken till noll.
Lagring = ingen
ProcessSizeMax=0
vanligtvis räcker det att bara ladda om systemd-konfigurationen.
systemctl daemon-reload
om detta fortfarande skapar en kärndump, starta om systemet.
inaktivera setuid processer dumpning deras minne
processer med förhöjda behörigheter (eller setuid bit), kan fortfarande kunna utföra en kärna dump, beroende på dina andra inställningar. Eftersom dessa processer vanligtvis har mer åtkomst kan de innehålla mer känsliga datasegment i minnet. Så dags att ändra detta också. Beteendet kan ändras med en sysctl-nyckel eller direkt via /proc-filsystemet. För permanenta inställningar används sysctl-kommandot och konfigurationen vanligtvis. En inställning kallas en ’nyckel’, som har ett relaterat värde kopplat till det (även känt som ett nyckelvärdespar).
för att inaktivera program med setuid-biten för att dumpa, Ställ in fs.suid_dumpable till noll.
echo "fs.suid_dumpable=0" >> /etc/sysctl.conf
ladda om sysctl-konfigurationen med-p-flaggan för att aktivera eventuella ändringar du gjort.
sysctl -p
vill du bara testa utan att göra permanenta förändringar? Använd sysctl -w följt av nyckeln=värde.
tips: med sysctl kan du ställa in ditt system och är ett bra sätt att härda Linux-kärnan.
aktivera kärndumpar
den främsta anledningen till att tillåta kärndumpar är för felsökningsändamål. Det dumpade minnet av processen kan användas för felsökningsproblem, vanligtvis av mer erfarna utvecklare. En programvaruleverantör kan be om att aktivera kärndumpar. Vanligtvis för att upptäcka varför en process kraschade i första hand och hitta den relaterade rutinen som orsakade den.
att aktivera kärndumpar på Linux liknar att inaktivera dem, förutom att några specifika detaljer ska konfigureras. Om du till exempel bara behöver detaljer från ett visst program kan du använda mjuka gränser. Detta görs genom att använda -Svilket indikerar att det är en mjuk gräns. -c anger storleken på en kärndump.
ulimit -S -c 0
nästa steg är att bara tillåta ’my-program-to-felsöka’ för att skapa en core dump.
ulimit -S -c unlimited my-program-to-troubleshoot
om du vill tillåta alla processer att använda kärndumpar, använd raden ovan utan programmet eller ställ in en systemgräns i /etc/security/limits.conf
* soft core unlimited
felsöka setuid-binärer
binärer som har en setuid-bituppsättning kan köras med root-behörigheter. Denna speciella typ av åtkomst måste begränsas så mycket som möjligt. Även för skapandet av kärndumpar måste den konfigureras korrekt. Detta görs med sysctl fs.suid_dumpable nyckel.
- 0 – inaktiverad
- 1-aktiverad
- 2 – aktiverad med begränsningar
så om du vill felsöka program med en setuid bit set, kan du tillfälligt ändra fs.suid_dumpable till 1 eller 2. Att ställa in den till 2 är att föredra eftersom det gör att kärndumparna endast kan läsas för rotanvändaren. Detta är ett bra alternativ för system med känslig data. Att ställa in alternativet till 1 är bättre lämpat för personliga utvecklingssystem.
skapa normala dumpfiler
ett av de stora mysterierna med Linux-system är där kärndumparna finns. Linux har ett knep för att fånga kärndumpar. Denna speciella inställning görs via sysctl-kärnan.core_pattern inställning eller/proc/sys/kernel / core_pattern. De flesta system kommer att ha ett rör (|) i denna inställning för att indikera att ett program måste ta hand om den genererade data. Så om du undrar var din kärndump går, följ röret!
Kärndumpar på Ubuntu-system kommer vanligtvis att Apport. För Red Hat – baserade system kan det omdirigeras till Automatic Bug Reporting Tool (ABRT).
du kan tillfälligt ändra den här inställningen genom att echoing ”core” till den filen, eller använd sysctl verktyget.
sysctl -w kernel.core_pattern=core
en viktig anmärkning är att denna förändring kanske inte räcker. Det beror också på din fs.suid_dumpable inställning. En varning loggas till din kernel logger om så är fallet.
September 06 15:51:18 härdning kärna: osäkra core_pattern används med suid_dumpable=2. Rörhanterare eller fullt kvalificerad kärndumpväg krävs.
vid behov ställa in din core_pattern till en fullständig sökväg, eventuellt med variabler som definierar vem som körde den, PID, etc.
sysctl-w kärna.core_pattern=/var / krasch / kärna.%u. % e. % p
i det här exemplet innehåller våra dumpar användar-id, programnamn och process-id.
Systemd core dumps
när du använder en modern Linux-distribution kommer du sannolikt att ha systemd aktiverat. Du kan behöva åsidosätta inställningar via / etc / sysctl.d / 50-coredump.conf och definiera hur och var du vill lagra dina kärndumpar.
använda systemd-coredump
din kärna.core_pattern kan definieras för att använda verktyget systemd-coredump. Standardvägen där kärndumpar lagras är sedan i/var/lib / systemd / coredump.
testa din konfiguration
de flesta andra handledning ger dig bara de inställningar som ska konfigureras. Men hur skulle du veta att saker fungerar som förväntat? Du måste testa det!
skapa en kärndump
alternativ 1: Skapa ett instabilt program
Låt oss skapa ett enkelt program. Dess primära mål är att krascha när den körs och sedan eventuellt skapa en kärndump. Installera gcc på ditt system och skapa en filkrasch.c i din hemkatalog.
int main(){ return 1/0;}
detta program startar huvudfunktionen och returnerar ett heltal (tal). Det delar dock 1 med noll, vilket inte är tillåtet och kommer att krascha. Nästa steg är att sammanställa vårt lilla buggy-program.
vårt instabila lilla program
även kompilatorn visar att vårt program innehåller ett allvarligt problem och visar en varning om det. Låt oss nu köra det och se om så är fallet.
en trevlig krasch!
från denna enda rad kan vi faktiskt lära oss några saker. Först och främst slutade det med ett undantag, särskilt med hänvisning till flytande punkter. Detta är ett decimaltalformat för program, så det kan indikera att något hände medan du gjorde lite matte. En annan slutsats är att kärnan dumpas på grund av tillägget (core dumped) i slutet. Om kärndumpar inaktiverades skulle detta inte visas.
bra, så med denna krasch ovan har vi nu en dumpad fil, eller hur? Inte direkt. Beroende på din Linux-distribution kanske det inte är så enkelt som det ser ut. Varje distribution handlar annorlunda med kärndumpar och standardinställningarna. De senaste Linux-distributionerna använder också systemd nu och reglerna har ändrats något med det också. Beroende på din konfiguration kan du behöva söka efter dina kärndumpar. Så här är några tips för att säkerställa att allt är korrekt konfigurerat.
alternativ 2: döda en pågående process
istället för att använda ett testprogram kan du också avsluta en befintlig process. Detta görs genom att använda SIGSEGV, som är kort för segmenteringsöverträdelse och även känd som ett segmenteringsfel.
kill -s SIGSEGV PID
om du ersätter PID med ”$ $ ” kommer det aktuella programmet (troligen ditt skal) att krascha. Allt för vetenskapen, eller hur?
alternativ 3: Använda gdb
om du har installerat utvecklarfelsökningsverktyget gdb, bifoga sedan till en valfri process med dess process-ID (PID).
gdb -p 1234
sedan när du är på gdb-prompten, generera kärndumpen genom att åberopa generate-core-file-instruktionen. Efter att ha använt det här kommandot ska det returnera utmatningen.
sparade corefile kärna.1234
kontrollera ulimit-inställningar
ulimit-inställningarna definierar vad som kan hända när ETT program kraschar. Så det är säkert att först kontrollera detta, för både root och en vanlig icke-privilegierad användare.
kontrollera hård gräns för kärndumpar:
ulimit -H -c
Kontrollera också mjuk gräns:
ulimit -S -c
kontrollera kärnmönstret
använd filsystemet /proc för att samla in värdet och ändra det tillfälligt under testningen. Om du föredrar att använda sysctl, fråga sedan kärnan.core_pattern nyckel.
cat /proc/sys/kernel/core_pattern
det kan visa något så här:
|/usr/share/apport/apport %p %s %c %P
i det här fallet kommer en krasch att ledas till apport-verktyget. Så det betyder att kraschar kommer att analyseras av Apport. Normalt finns kraschar i /var/crash, men kan också vara i /var/spool eller/var/lib / systemd / coredump på andra Linux-distributioner.
kontrollera tidskriften (systemd)
i vårt fall journalctl visar vår krasch, så det är en början.
efter att ha kontrollerat alla dessa inställningar borde du kunna skapa en fin kärndump.
slutsats
Kärndumpar kan vara användbara för felsökning, men en katastrof för att läcka känsliga data. Inaktivera kärndumpar när det är möjligt och aktivera dem bara när det verkligen behövs. Kontrollera i så fall om filerna lagras säkert så att vanliga användare inte kan se data. Och oberoende av vilket val du gjorde, testa alltid om din konfiguration fungerar exakt som du förväntar dig att den ska fungera.