hvert system har brug for kørende processer for at opfylde sit primære mål. Men nogle gange går det galt, og en proces kan gå ned. Afhængigt af systemets konfiguration oprettes en kernedump. Med andre ord gemmes et hukommelsesbillede af den nedbrudte proces. Udtrykket kerne henviser faktisk til den gamle magnetiske kernehukommelse fra ældre systemer. Selvom denne type hukommelse ikke længere bruges, bruger vi stadig dette udtryk på Linuks-systemer. Nok til historien, lad os konfigurere vores system til korrekt håndtering af kernedumper.
Indholdsfortegnelse
lossepladser
de fleste lossepladser er som standard aktiveret. Som altid er der en afvejning at gøre her. På den ene side ønsker vi at indsamle data for forbedret stabilitet og fejlfinding. På den anden side ønsker vi at begrænse fejlfindingsdataene og undgå at lække følsomme data.
den første mulighed er god til maskiner, hvor ustabile programmer skal undersøges, som en udviklers arbejdsstation. Den anden mulighed er bedre egnet til produktionssystemer, der lagrer eller behandler følsomme data.
Deaktiver core dumps
det er fornuftigt at deaktivere alle core dumps som standard for alle dine systemer. Dette skyldes, at filerne optager diskplads og kan indeholde følsomme data. Så hvis du ikke har brug for kernedumpene til fejlfindingsformål, er det en sikker mulighed at deaktivere dem.
mulighed 1: ulimit via konfigurationsfilen
for at deaktivere kernedump skal vi indstille en ulimit værdi. Dette gøres via/etc/sikkerhed / grænser.conf fil og definerer nogle shell specifikke begrænsninger.
godt at vide er, at der er bløde og hårde grænser. En hård grænse er noget, der aldrig kan tilsidesættes, mens en blød grænse muligvis kun gælder for bestemte brugere. Hvis vi gerne vil sikre, at ingen proces kan skabe et kernedump, kan vi indstille dem begge til nul. Selvom det kan se ud som en boolsk (0 = falsk, 1 = Sand), angiver den faktisk den tilladte størrelse.
* blød kerne 0
* hård kerne 0
asterisk-tegnet betyder, at det gælder for alle brugere. Den anden kolonne angiver, om vi vil bruge en hård eller blød grænse, efterfulgt af kolonnerne, der angiver indstillingen og værdien.
valgmulighed 2: Konfigurer ulimit via profil
værdierne for ulimit kan også indstilles via /etc/profile eller en brugerdefineret fil i /etc/profile.d directory. Sidstnævnte foretrækkes, når den er tilgængelig. For eksempel ved at oprette en fil med navnet /etc/profile.d/disable-coredumps.sh.
echo “ulimit-c 0 > / dev / null 2>&1” > /etc / profil.d / Deaktiver-coredumps.sh
denne kommando tilføjer indstillingen til en ny fil og sætter både den bløde og hårde grænse til nul. Hver bruger får denne værdi, når han logger ind.
udover ulimit-indstillinger er der også kerneindstillinger at overveje. Så at vælge en af mulighederne er det første skridt.
Mulighed 3: Deaktiver via systemd
når du bruger systemd og systemd-coredump-tjenesten, skal du ændre coredump.conf fil. Denne fil er sandsynligvis placeret på / usr/lib / sysctl.d / 50-coredump.conf. Da systemd har et sæt filer, skal du sørge for at kontrollere de andre som:
Indstil Lagringsindstillingen til ‘ingen’. For at begrænse den maksimale størrelse til nul.
Opbevaring=Ingen
=0
det er typisk tilstrækkeligt at bare genindlæse systemd-konfigurationen.
systemctl daemon-reload
hvis dette stadig skaber et kernedump, skal du genstarte systemet.
Deaktiver setuid-processer, der dumper deres hukommelse
processer med forhøjede tilladelser (eller setuid-bit), kan muligvis stadig udføre en kernedump, afhængigt af dine andre indstillinger. Da disse processer normalt har mere adgang, kan de indeholde mere følsomme datasegmenter i hukommelsen. Så tid til at ændre dette så godt. Adfærden kan ændres med en sysctl-nøgle eller direkte via /proc-filsystemet. For permanente indstillinger bruges sysctl-kommandoen og konfigurationen typisk. En indstilling kaldes en ‘nøgle’, som har en relateret værdi knyttet til den (også kendt som et nøgleværdipar).
for at deaktivere programmet med setuid bit til dump, skal du indstille fs.suid_dumpable til nul.
echo "fs.suid_dumpable=0" >> /etc/sysctl.conf
Genindlæs sysctl-konfigurationen med-p-flaget for at aktivere eventuelle ændringer, du har foretaget.
sysctl -p
vil du bare teste uden at foretage permanente ændringer? Brug sysctl -w efterfulgt af nøglen=værdi.
Tip: ved hjælp af sysctl kan du tune dit system og er en god måde at hærde kernen på.
aktiver kernedump
den primære årsag til at tillade kernedump er til fejlfindingsformål. Den dumpede hukommelse af processen kan bruges til fejlretningsproblemer, normalt af mere erfarne udviklere. En leverandør kan bede om at aktivere core lossepladser. Normalt for at opdage, hvorfor en proces styrtede ned i første omgang og finde den relaterede rutine, der forårsagede den.
aktivering af kernedump på Linuk svarer til at deaktivere dem, bortset fra at nogle få specifikke detaljer skal konfigureres. For eksempel, hvis du kun har brug for detaljer fra et bestemt program, kan du bruge bløde grænser. Dette gøres ved at bruge -S, hvilket indikerer, at det er en blød grænse. -c angiver størrelsen på en kernedump.
ulimit -S -c 0
næste trin er kun at tillade ‘my-program-to-fejlfinding’ for at oprette et kernedump.
ulimit -S -c unlimited my-program-to-troubleshoot
hvis du vil tillade alle processer at bruge kernedumper, skal du bruge linjen ovenfor uden programmet eller indstille en systemgrænse i /etc/security/limits.conf
* soft core unlimited
fejlfinding af setuid-binære filer
binære filer, der har et setuid-bitsæt, kan køre med rodtilladelser. Denne særlige type adgang skal begrænses så meget som muligt. Også til oprettelse af kernedumper skal den konfigureres korrekt. Dette gøres med sysctl fs.suid_dumpable nøgle.
- 0 – deaktiveret
- 1 – aktiveret
- 2 – aktiveret med begrænsninger
så hvis du kan lide at fejlfinde programmer med et setuid-bitsæt, kan du midlertidigt ændre fs.suid_dumpable til 1 eller 2. Indstilling af det til 2 foretrækkes, da dette gør kernedumpene kun læsbare for rodbrugeren. Dette er et godt alternativ til systemer med følsomme data. Indstilling af indstillingen til 1 er bedre egnet til personlige udviklingssystemer.
Opret normale dump-filer
et af de store mysterier med Linuks-systemer er, hvor kernedumpene er placeret. Vi har et trick på plads til at fange kernedepoter. Denne særlige indstilling udføres via sysctl-kernen.core_pattern indstilling eller/proc/sys/kernel / core_pattern. De fleste systemer vil have et rør (|) i denne indstilling for at indikere, at et program skal tage sig af de genererede data. Så hvis du spekulerer på, hvor din kerne dump går, følg røret!
Core dumps på Ubuntu-systemer vil typisk Apport. For Red Hat-baserede systemer kan det omdirigeres til automatisk Fejlrapporteringsværktøj (ABRT).
du kan midlertidigt ændre denne indstilling ved at gentage “core” til den pågældende fil eller bruge værktøjet sysctl.
sysctl -w kernel.core_pattern=core
en vigtig note er, at denne ændring måske ikke er nok. Det afhænger også af din fs.suid_dumpable indstilling. En advarsel vil blive logget på din kernelogger, hvis det er tilfældet.
September 06 15:51:18 hærdning kerne: usikre core_pattern bruges med suid_dumpable=2. Pipe handleren eller fuldt kvalificeret kerne dump sti kræves.
når det er nødvendigt, skal du indstille din core_pattern til en fuld sti, eventuelt med variabler, der definerer, hvem der kørte den, PID osv.
sysctl-V kerne.core_pattern= / var / nedbrud / kerne.%u. % e.%p
i dette eksempel vil vores dumps indeholde bruger-id, programnavn og Proces-id.
Systemd core dumps
når du bruger en moderne distribution, vil du højst sandsynligt have systemd aktiveret. Du skal muligvis tilsidesætte indstillinger via/etc / sysctl.d / 50-coredump.conf og definere, hvordan og hvor du ønsker at gemme din kerne lossepladser.
brug af systemd-coredump
din kerne.core_pattern kan defineres til at bruge systemd-coredump-værktøjet. Standardstien, hvor kernedump er gemt, er derefter i /var/lib/systemd/coredump.
test af din konfiguration
de fleste andre tutorials giver dig bare de indstillinger, der skal konfigureres. Men hvordan ville du vide, at tingene fungerer som forventet? Du bliver nødt til at teste det!
Opret en core dump
mulighed 1: Opret et ustabilt program
lad os oprette et simpelt program. Dets primære mål er at gå ned, når det udføres, og derefter eventuelt oprette en kernedump. Installer gcc på dit system og oprette en fil nedbrud.c i din hjemmekatalog.
int main(){ return 1/0;}
dette program starter hovedfunktionen og returnerer en heltalsværdi (nummer). Det er dog at dividere 1 med nul, hvilket ikke er tilladt og vil gå ned. Det næste trin er at kompilere vores lille buggy-program.
vores ustabile lille program
selv kompilatoren viser, at vores program indeholder et alvorligt problem og viser en advarsel om det. Lad os nu køre det og se om dette er tilfældet.
et godt nedbrud!
fra denne enkelt linje kan vi faktisk lære et par ting. Først og fremmest, at det holder op med en undtagelse, der specifikt henviser til flydende punkter. Dette er et decimaltalformat for programmer, så det kan indikere, at der skete noget, mens du lavede noget matematik. En anden konklusion er, at kernen dumpes på grund af (kerne dumpet) tilsætning i slutningen. Hvis core lossepladser blev deaktiveret, ville dette ikke vises.
fantastisk, så med dette nedbrud ovenfor har vi nu en dumpet fil, ikke? Ikke ligefrem. Afhængigt af din distribution er tingene måske ikke så enkle, som det ser ud. Hver distribution omhandler forskelligt med core lossepladser og standardindstillingerne. De seneste distributioner bruger også systemd nu, og reglerne er også lidt ændret med det. Afhængigt af din konfiguration skal du muligvis søge efter dine kernedump. Så her er nogle tip til at sikre, at alt er konfigureret korrekt.
Mulighed 2: Dræb en kørende proces
i stedet for at bruge et testprogram kan du også afslutte en eksisterende proces. Dette gøres ved at bruge SIGSEGV, som er en forkortelse for segmenteringsovertrædelse og også kendt som en segmenteringsfejl.
kill -s SIGSEGV PID
hvis du erstatter PID med “$ $ ” det aktuelle program (sandsynligvis din shell) vil gå ned. Alt for videnskab, ikke?
valgmulighed 3: Brug af gdb
hvis du har udviklerfejlfejlværktøjet gdb installeret, skal du vedhæfte en valgproces ved hjælp af dets proces-ID (PID).
gdb -p 1234
så når du er ved gdb-prompten, skal du generere kernedumpen ved at påberåbe sig generer-core-filinstruktionen. Når du har brugt denne kommando, skal den returnere dig output.
gemt corefile core.1234
kontroller ulimit-indstillinger
ulimit-indstillingerne definerer, hvad der kan ske, når ET program går ned. Så det er sikkert at først kontrollere dette for både root og en normal ikke-privilegeret bruger.
kontroller hård grænse for kernedumper:
ulimit -H -c
Tjek også blød grænse:
ulimit -S -c
kontroller kernemønsteret
brug /proc-filsystemet til at samle værdien og ændre den midlertidigt under testningen. Hvis du foretrækker at bruge sysctl, skal du forespørge kernen.core_pattern nøgle.
cat /proc/sys/kernel/core_pattern
det kan vise noget som dette:
|/usr/share/apport/apport %p %s %c %P
i dette tilfælde ledes et nedbrud til apport-værktøjet. Så det betyder, at nedbrud vil blive analyseret af Apport. Normalt findes nedbrud i /var/crash, men kan også være i /var/spool eller /var/lib/systemd/coredump på andre distributioner.
Tjek journalen (systemd)
i vores tilfælde journalctl viser vores nedbrud, så det er en start.
når du har kontrolleret alle disse indstillinger, skal du være i stand til at oprette en dejlig kernedump.
konklusion
Kernedumper kan være nyttige til fejlfinding, men en katastrofe for lækage af følsomme data. Deaktiver kerne lossepladser når det er muligt, og kun aktivere dem, når det virkelig er nødvendigt. I så fald skal du kontrollere, om filerne er gemt sikkert, så normale brugere ikke kan se dataene. Og uafhængigt af hvilket valg du har lavet, skal du altid teste, om din konfiguration fungerer nøjagtigt, som du forventer, at den fungerer.