elk systeem heeft draaiende processen nodig om zijn primaire doel te bereiken. Maar soms gaat het mis en kan een proces crashen. Afhankelijk van de configuratie van het systeem wordt een core dump gemaakt. Met andere woorden, een geheugen snapshot van het gecrashte proces wordt opgeslagen. De term kern verwijst eigenlijk naar het oude magnetische kerngeheugen van oudere systemen. Hoewel dit type geheugen niet meer wordt gebruikt, gebruiken we deze term nog steeds op Linux systemen. Genoeg voor de geschiedenis, laten we ons Linux systeem configureren om core dumps goed af te handelen.
inhoudsopgave:
Linux en core dumps
de meeste Linux systemen hebben core dumps standaard ingeschakeld. Zoals altijd is er hier een afweging te maken. Aan de ene kant willen we gegevens verzamelen voor verbeterde stabiliteit en probleemoplossing. Aan de andere kant willen we de debuggegevens beperken en voorkomen dat gevoelige gegevens lekken.
de eerste optie is goed voor machines waar onstabiele programma ‘ s moeten worden onderzocht, zoals het werkstation van een ontwikkelaar. De tweede optie is beter geschikt voor productiesystemen die gevoelige gegevens opslaan of verwerken.
Disable core dumps
het is zinvol om alle core dumps op Linux standaard uit te schakelen voor al uw systemen. Dit komt omdat de bestanden schijfruimte innemen en gevoelige gegevens kunnen bevatten. Dus als je de core dumps niet nodig hebt voor het oplossen van problemen, is het uitschakelen ervan een veilige optie.
Optie 1: ulimit via het configuratiebestand
om core dumps uit te schakelen moeten we een waarde ulimit instellen. Dit wordt gedaan via de/etc/security / limits.conf bestand en definieert een aantal shell specifieke beperkingen.
goed om te weten is dat er zachte en harde limieten zijn. Een harde limiet is iets dat nooit kan worden overschreven, terwijl een zachte limiet alleen van toepassing is voor specifieke gebruikers. Als we ervoor willen zorgen dat geen proces een core dump kan maken, kunnen we ze beide op nul zetten. Hoewel het eruit kan zien als een boolean (0 = False, 1 = True), geeft het eigenlijk de toegestane grootte aan.
* zachte kern 0
* harde kern 0
het sterretje betekent dat het van toepassing is op alle gebruikers. De tweede kolom geeft aan of we een harde of zachte limiet willen gebruiken, gevolgd door de kolommen met de instelling en de waarde.
Optie 2: ulimit configureren via profiel
de waarden voor ulimit kunnen ook worden ingesteld via /etc/profile of een aangepast bestand in het /etc/profile.d directory. Dit laatste heeft de voorkeur wanneer het beschikbaar is. Bijvoorbeeld door een bestand met de naam /aan te maken etc/profile.d/disable-coredumps.sh.
echo “ulimit-c 0 > / dev / null 2>&1” > /etc / profiel.d / disable-coredumps.sh
dit commando voegt de instelling toe aan een nieuw bestand en stelt zowel de zachte als de harde limiet in op nul. Elke gebruiker krijgt deze waarde bij het inloggen.
naast ulimit-instellingen zijn er ook kernel-instellingen om te overwegen. Dus het kiezen van een van de opties is de eerste stap.
optie 3: uitschakelen via systemd
bij gebruik van systemd en de systemd-coredump service, verander de coredump.conf file. Dit bestand bevindt zich waarschijnlijk in /usr/lib/sysctl.d / 50-kernpomp.conf. Als systemd heeft een set van bestanden, ervoor te zorgen om de anderen te controleren als:
Stel de Opslaginstelling in op’geen’. Configureer vervolgens ProcessSizeMax om de maximale grootte te beperken tot nul.
Storage = none
Processizemax=0
meestal is het voldoende om de systemd configuratie te herladen.
systemctl daemon-reload
als dit nog steeds een core dump maakt, start dan het systeem opnieuw op.
setuid-processen uitschakelen die hun geheugen dumpen
processen met verhoogde rechten (of de setuid-bit), kunnen mogelijk nog steeds een core-dump uitvoeren, afhankelijk van uw andere instellingen. Aangezien deze processen meestal meer toegang hebben, kunnen ze gevoeliger datasegmenten in het geheugen bevatten. Dus tijd om dit ook te veranderen. Het gedrag kan worden gewijzigd met een sysctl sleutel, of direct via het /proc bestandssysteem. Voor permanente instellingen worden meestal de sysctl-opdracht en-configuratie gebruikt. Een instelling wordt een ‘sleutel’ genoemd, die een daaraan verbonden waarde heeft (ook bekend als een sleutel-waarde paar).
om programma met de setuid Bit uit te schakelen om te dumpen, stelt u de fs in.suid_dumpable tot nul.
echo "fs.suid_dumpable=0" >> /etc/sysctl.conf
herlaad de sysctl configuratie met de-p vlag om eventuele wijzigingen te activeren.
sysctl -p
wil je gewoon testen zonder permanente veranderingen aan te brengen? Gebruik sysctl -w gevolgd door de key=value.
Tip: met sysctl kun je je systeem afstemmen en is een goede manier om de Linux kernel te harden.
core dumps inschakelen
de belangrijkste reden om core dumps toe te staan is om problemen op te lossen. Het gedumpte geheugen van het proces kan worden gebruikt voor het debuggen van problemen, meestal door meer ervaren ontwikkelaars. Een softwareleverancier kan vragen om core dumps in te schakelen. Meestal om te ontdekken waarom een proces crashte in de eerste plaats en vind de gerelateerde routine die het veroorzaakt.
het inschakelen van core dumps op Linux is vergelijkbaar met het uitschakelen ervan, behalve dat een paar specifieke details moeten worden geconfigureerd. Als u bijvoorbeeld alleen details van een bepaald programma nodig hebt, kunt u zachte limieten gebruiken. Dit wordt gedaan met -S, wat aangeeft dat het een zachte limiet is. De -c geeft de grootte van een kerndump aan.
ulimit -S -c 0
de volgende stap is om alleen ‘my-program-to-troubleshoot’ toe te staan om een core dump te maken.
ulimit -S -c unlimited my-program-to-troubleshoot
als je alle processen wilt toestaan om core dumps te gebruiken, gebruik dan de bovenstaande regel zonder het programma, of stel een systeemlimiet in in /etc/security/limits.conf
* soft core unlimited
problemen oplossen met setuid-binaries
Binaries die een setuid-bitset hebben, kunnen worden uitgevoerd met root-rechten. Dit speciale type toegang moet zoveel mogelijk worden beperkt. Ook voor het maken van core dumps, het moet goed worden geconfigureerd. Dit wordt gedaan met de sysctl fs.suid_dumpable sleutel.
- 0 – disabled
- 1-enabled
- 2-enabled with restrictions
dus als u problemen wilt oplossen met programma ‘ s met een setuid bit set, kunt u tijdelijk de fs wijzigen.suid_dumpable tot 1 of 2. Het instellen op 2 heeft de voorkeur omdat dit de core dumps alleen leesbaar maakt voor de root gebruiker. Dit is een goed alternatief voor systemen met gevoelige gegevens. Het instellen van de optie op 1 is beter geschikt voor persoonlijke ontwikkelingssystemen.
maak normale dumpbestanden
een van de grote mysteries met Linux-systemen is waar de core dumps zich bevinden. Linux heeft een truc om core dumps vast te leggen. Deze specifieke instelling wordt gedaan via de sysctl kernel.core_pattern instelling of / proc/sys/kernel / core_pattern. De meeste systemen zullen een pipe (|) in deze instelling hebben om aan te geven dat een programma de gegenereerde data moet verzorgen. Dus als je je afvraagt waar je kern dump gaat, Volg de pijp!
Core-dumps op Ubuntu-systemen gaan doorgaans naar Apport. Voor Red Hat gebaseerde systemen kan het worden doorgestuurd naar Automatic Bug Reporting Tool (ABRT).
u kunt deze instelling tijdelijk wijzigen door “core” in dat bestand te echoën, of gebruik het hulpprogramma sysctl.
sysctl -w kernel.core_pattern=core
een belangrijke opmerking is dat deze verandering misschien niet genoeg is. Het hangt ook af van je fs.suid_dumpable instelling. Als dat het geval is, wordt er een waarschuwing ingelogd in je kernel logger.
Sep 06 15: 51:18 Harding kernel: Unsafe core_pattern used with suid_dumpable=2. Pipe handler of volledig gekwalificeerd core dump pad vereist.
indien nodig stel je core_pattern in op een volledig pad, optioneel met variabelen die bepalen wie het draaide, de PID, enz.
sysctl-w kernel.core_pattern= / var / crash / core.%u. % e. % p
in dit voorbeeld zullen onze dumps gebruikers-ID, programmanaam en proces-id bevatten.
Systemd core dumps
als u een moderne Linux-distributie gebruikt, hebt u systemd waarschijnlijk ingeschakeld. Het kan nodig zijn om instellingen te overschrijven via /etc / sysctl.d / 50-kernpomp.conf en bepalen hoe en waar u uw core dumps wilt opslaan.
systemd-coredump
uw kernel gebruiken.core_pattern kan worden gedefinieerd om het systemd-coredump hulpprogramma te gebruiken. Het standaard pad waar core dumps worden opgeslagen is dan in / var/lib/systemd / coredump.
uw configuratie testen
de meeste andere tutorials geven u gewoon de instellingen die u moet instellen. Maar hoe weet je dat dingen werken zoals verwacht? Je moet het testen!
Maak een core dump
Optie 1: Maak een onstabiel programma
laten we een eenvoudig programma maken. Het primaire doel is om te crashen wanneer wordt uitgevoerd en vervolgens optioneel een core dump te maken. Installeer gcc op uw systeem en maak een bestand crash.c in je persoonlijke map.
int main(){ return 1/0;}
dit programma start de hoofdfunctie en geeft een integer waarde (getal) terug. Echter, het is het delen van 1 door nul, die niet is toegestaan en zal crashen. De volgende stap is het samenstellen van ons buggy programma.
ons onstabiele kleine programma
zelfs de compiler toont ons programma bevat een ernstig probleem en geeft een waarschuwing over het. Laten we nu kijken of dit het geval is.
een mooie crash!
van deze enkele regel kunnen we eigenlijk een paar dingen leren. Allereerst dat het stopt met een uitzondering, specifiek verwijzend naar zwevende punten. Dit is een decimaal getal formaat voor programma ‘ s, dus het kan aangeven dat er iets gebeurd is tijdens het doen van wat wiskunde. Een andere conclusie is dat de kern wordt gedumpt als gevolg van de (kern gedumpt) toevoeging aan het einde. Als core dumps waren uitgeschakeld, zou dit niet verschijnen.
geweldig, dus met deze crash hierboven hebben we nu een gedumpt bestand, toch? Niet precies. Afhankelijk van je Linux distributie kunnen dingen niet zo eenvoudig zijn als het eruit ziet. Elke distributie behandelt anders met core dumps en de standaardinstellingen. De meest recente Linux distributies maken nu ook gebruik van systemd en de regels zijn daarmee ook enigszins gewijzigd. Afhankelijk van je configuratie moet je misschien zoeken naar je core dumps. Dus hier zijn enkele tips om ervoor te zorgen dat alles correct is geconfigureerd.
Optie 2: een lopend proces afbreken
in plaats van een testprogramma te gebruiken, kunt u ook een bestaand proces beëindigen. Dit wordt gedaan met behulp van de SIGSEGV, die kort is voor segmentatie overtreding en ook bekend als een segmentatie fout.
kill -s SIGSEGV PID
als je PID vervangt door “$ $ ” zal het huidige programma (hoogstwaarschijnlijk je shell) crashen. Alles voor de wetenschap, toch?
optie 3: gebruik gdb
als u de ontwikkelaar debugging tool GDB hebt geïnstalleerd, koppel dan aan een proces naar keuze met behulp van zijn proces-ID (PID).
gdb -p 1234
als je dan achter de GDB prompt staat, genereer je de core dump door de generate-core-file instructie aan te roepen. Na het gebruik van dit commando, zou het je uitvoer terug moeten geven.
opgeslagen corebestand core.1234
Controleer ulimit instellingen
de ulimit instellingen bepalen wat er kan gebeuren als een programma crasht. Het is dus veilig om dit eerst te controleren, zowel voor root als voor een normale niet-geprivilegieerde gebruiker.
harde limiet voor kerndumps controleren:
ulimit -H -c
Check soft limit ook:
ulimit -S -c
controleer het core pattern
gebruik het / proc bestandssysteem om de waarde te verzamelen en tijdelijk te wijzigen tijdens het testen. Als je liever sysctl gebruikt, vraag dan de kernel aan.core_patroon sleutel.
cat /proc/sys/kernel/core_pattern
het zou iets als dit kunnen laten zien:
|/usr/share/apport/apport %p %s %c %P
In dit geval wordt een crash naar het apport-hulpprogramma geleid. Dit betekent dat crashes worden geanalyseerd door Apport. Normaal gesproken worden crashes gevonden in /var/crash, maar kunnen ook in /var/spool of /var/lib/systemd/coredump op andere Linux distributies staan.
controleer het journaal (systemd)
in ons geval journalctl toont onze crash, dus dat is een start.
na het controleren van al deze instellingen zou je in staat moeten zijn om een mooie core dump te maken.
conclusie
Core dumps kunnen nuttig zijn voor het oplossen van problemen, maar een ramp voor het lekken van gevoelige gegevens. Schakel core dumps uit indien mogelijk, en schakel ze alleen in wanneer dat echt nodig is. Controleer in dat geval of de bestanden veilig zijn opgeslagen, zodat normale gebruikers de gegevens niet kunnen zien. En onafhankelijk van welke keuze je hebt gemaakt, test altijd of je configuratie precies werkt zoals je verwacht.