minden rendszernek futó folyamatokra van szüksége az elsődleges cél eléréséhez. De néha a dolgok rosszra fordulnak, és egy folyamat összeomlik. A rendszer konfigurációjától függően létrejön egy core dump. Más szavakkal, az összeomlott folyamat memória pillanatképe tárolódik. A mag kifejezés valójában a régebbi rendszerek régi mágneses magmemóriájára utal. Bár ezt a típusú memóriát már nem használják, ezt a kifejezést továbbra is használjuk Linux rendszereken. Elég a történelemhez, konfiguráljuk Linux rendszerünket úgy, hogy megfelelően kezelje az alapvető hulladéklerakókat.
Tartalomjegyzék
Linux és core dumps
a legtöbb Linux rendszerben alapértelmezés szerint engedélyezve van a core dumps. Mint mindig, itt is kompromisszumot kell kötni. Egyrészt adatokat szeretnénk gyűjteni a jobb stabilitás és a hibaelhárítás érdekében. Másrészt szeretnénk korlátozni a hibakeresési adatokat, és elkerülni az érzékeny adatok kiszivárgását.
az első lehetőség olyan gépekhez jó, ahol instabil programokat kell vizsgálni, például egy fejlesztő munkaállomásához. A második lehetőség jobban megfelel az érzékeny adatok tárolására vagy feldolgozására szolgáló termelési rendszereknek.
Disable core guba
érdemes letiltani minden core guba Linux alapértelmezés szerint az összes rendszer. Ez azért van, mert a fájlok lemezterületet foglalnak el, és érzékeny adatokat tartalmazhatnak. Tehát, ha hibaelhárítási célokra nincs szüksége a magraktárakra, akkor azok letiltása biztonságos lehetőség.
1.Lehetőség: ulimit a
konfigurációs fájl segítségével a maglerakók letiltásához be kell állítanunk egy ulimit értéket. Ez az /etc / security / limits fájlon keresztül történik.conf fájlt, és meghatároz néhány shell specifikus korlátozásokat.
jó tudni, hogy vannak puha és kemény határok. A kemény korlát olyan dolog, amelyet soha nem lehet felülírni, míg a puha korlát csak bizonyos felhasználók számára alkalmazható. Ha biztosítani szeretnénk, hogy egyetlen folyamat sem tud létrehozni egy core dump-ot, akkor mindkettőt nullára állíthatjuk. Bár úgy néz ki, mint egy logikai (0 = hamis, 1 = igaz), valójában a megengedett méretet jelzi.
* lágy mag 0
* kemény mag 0
a csillagjel azt jelenti, hogy minden felhasználóra vonatkozik. A második oszlop meghatározza, hogy kemény vagy puha korlátot akarunk-e használni, majd az oszlopok megadják a beállítást és az értéket.
2.lehetőség: az ulimit beállítása profilon keresztül
az ulimit értékei az /etc/profile fájlban vagy az /etc/profile fájlban is beállíthatók.d könyvtár. Ez utóbbi előnyös, ha rendelkezésre áll. Például egy /nevű fájl létrehozásával etc/profile.d/disable-coredumps.sh.
echo “ulimit-c 0 > / dev / null 2>&1” > /stb. / profil.d / disable-coredumps.sh
ez a parancs hozzáadja a beállítást egy új fájlhoz, és mind a lágy, mind a kemény korlátot nullára állítja. Minden felhasználó megkapja ezt az értéket bejelentkezéskor.
az ulimit beállítások mellett a rendszermag beállításait is figyelembe kell venni. Tehát az egyik lehetőség kiválasztása az első lépés.
3.lehetőség: tiltsa le a systemd
segítségével a systemd és a systemd-coredump Szolgáltatás használatakor módosítsa a coredump-ot.conf fájl. Ez a fájl valószínűleg a /usr/lib/sysctl könyvtárban található.d / 50-coredump.conf. Mivel a systemd egy sor fájlt tartalmaz, ellenőrizze a többi hasonlót:
állítsa a tárolási beállítást ‘Nincs’értékre. Ezután konfigurálja a Processizemax-ot úgy, hogy a maximális méretet nullára korlátozza.
Tárolás = nincs
ProcessSizeMax=0
általában elegendő csak újratölteni a systemd konfigurációt.
systemctl daemon-reload
ha ez még mindig létrehoz egy core dump-ot, akkor indítsa újra a rendszert.
letiltása setuid folyamatok dömping a memória
folyamatok emelt jogosultságokkal (vagy a setuid bit), lehet, hogy továbbra is képes végrehajtani a mag dump, attól függően, hogy a többi beállítást. Mivel ezek a folyamatok általában több hozzáféréssel rendelkeznek, érzékenyebb adatszegmenseket tartalmazhatnak a memóriában. Ideje ezen is változtatni. A viselkedés megváltoztatható egy sysctl kulccsal, vagy közvetlenül a /proc fájlrendszeren keresztül. Az állandó beállításokhoz általában a sysctl parancsot és konfigurációt használják. A beállítást ‘kulcs’-nak nevezzük, amelyhez kapcsolódó érték kapcsolódik (más néven kulcs-érték pár).
a dump setuid bittel rendelkező program letiltásához állítsa be az fs-t.suid_dumpable nullára.
echo "fs.suid_dumpable=0" >> /etc/sysctl.conf
töltse be újra a sysctl konfigurációt a-p jelzővel a végrehajtott módosítások aktiválásához.
sysctl -p
csak azt, hogy teszteljék anélkül, hogy állandó változások? Használja a sysctl -w billentyűt, amelyet a kulcs=érték követ.
tipp: a sysctl használatával beállíthatja a rendszert, és ez egy jó módszer a Linux kernel keményítésére.
core dumps engedélyezése
a core dumps engedélyezésének elsődleges oka a hibaelhárítás. A dömpingelt memória a folyamat lehet használni hibakeresés problémák, általában tapasztaltabb Fejlesztők. A szoftvergyártó kérheti az alapvető hulladéklerakók engedélyezését. Általában, hogy felfedezzék, miért egy folyamat összeomlott az első helyen, és megtalálja a kapcsolódó rutin okozta.
a core dump engedélyezése Linuxon hasonló a letiltásukhoz, azzal a különbséggel, hogy néhány konkrét részletet konfigurálni kell. Például, ha csak egy adott program részleteire van szüksége, használhatja a puha korlátokat. Ez a -S használatával történik, ami azt jelzi, hogy ez egy puha határ. A -c a magdömping méretét jelöli.
ulimit -S -c 0
a következő lépés az, hogy csak a’ My-program-to-troubleshoot ‘ engedélyezze a core dump létrehozását.
ulimit -S -c unlimited my-program-to-troubleshoot
ha azt szeretnénk, hogy az összes folyamat használja core gups, használja a fenti sort anélkül, hogy a program, vagy állítsa be a rendszer limit /etc/security/limits.conf
* soft core unlimited
a setuid binárisok hibaelhárítása
a setuid bitkészlettel rendelkező binárisok root jogosultságokkal futtathatók. Ezt a különleges típusú hozzáférést a lehető legnagyobb mértékben korlátozni kell. A maglerakók létrehozásához is megfelelően kell konfigurálni. Ez a sysctl fs segítségével történik.suid_dumpable kulcs.
- 0 – disabled
- 1-enabled
- 2-enabled with restrictions
tehát ha setuid bitkészlettel szeretné elhárítani a programokat, ideiglenesen módosíthatja az fs-t.suid_dumpable 1 vagy 2. Beállítás 2 előnyös, mivel ez teszi a core guba csak olvasható a root felhasználó. Ez jó alternatíva az érzékeny adatokkal rendelkező rendszerek számára. Az opció 1-re állítása jobban megfelel a személyes fejlesztési rendszereknek.
normál dump fájlok létrehozása
a Linux rendszerek egyik nagy rejtélye az, hogy hol találhatók a maglerakók. A Linuxnak van egy trükkje a maglerakók rögzítésére. Ez a beállítás a sysctl kernelen keresztül történik.core_pattern beállítás vagy /proc/sys/kernel/core_pattern. A legtöbb rendszer rendelkezik egy csővel (|) ebben a beállításban, jelezve, hogy egy programnak gondoskodnia kell a generált adatokról. Tehát, ha kíváncsi vagy, hová megy a magdugó, kövesse a csövet!
az Ubuntu rendszereken a mag-lerakók általában Apportálni fognak. A Red Hat alapú rendszerek lehet átirányítani automatikus Hibajelentő eszköz (ABRT).
ideiglenesen módosíthatja ezt a beállítást, ha a “core” – T visszhangozza a fájlra, vagy használja a sysctl segédprogramot.
sysctl -w kernel.core_pattern=core
fontos megjegyezni, hogy ez a változás nem biztos, hogy elegendő. Ez az fs-től is függ.suid_dumpable beállítás. Ha ez a helyzet, egy figyelmeztetés kerül naplózásra a kernel naplózójába.
Sep 06 15:51:18 edzés kernel: nem biztonságos core_pattern használt suid_dumpable=2. Csőkezelő vagy teljesen minősített mag-lerakási útvonal szükséges.
ha szükséges, állítsa be a core_pattern-t egy teljes elérési útra, opcionálisan olyan változókkal, amelyek meghatározzák, hogy ki futtatta, a PID-t stb.
sysctl-w kernel.core_pattern= / var/összeomlás / mag.%u.%e.%p
ebben a példában a hulladéklerakók tartalmazzák a felhasználói azonosítót, a program nevét és a folyamat azonosítóját.
Systemd core guba
ha egy modern Linux disztribúció akkor valószínűleg systemd engedélyezve. Előfordulhat, hogy felül kell írnunk a beállításokat az /etc/sysctl állományban.d / 50-coredump.conf és határozza meg, hogyan és hol szeretné tárolni a core gups.
használata systemd-coredump
a kernel.a core_pattern definiálható a systemd-coredump segédprogram használatához. Az alapértelmezett elérési út a /var/lib/systemd/coredump könyvtárban található.
a konfiguráció tesztelése
a legtöbb egyéb oktatóanyag csak megadja a konfigurálandó beállításokat. De honnan tudod, hogy a dolgok a várt módon működnek? Meg kell tesztelni!
core dump létrehozása
1.Lehetőség: instabil program létrehozása
hozzunk létre egy egyszerű programot. Elsődleges célja, hogy összeomlik, amikor végrehajtják, majd opcionálisan hozzon létre egy mag dump. Telepítse a gcc-t a rendszerére, és hozzon létre egy fájlösszeomlást.c a saját könyvtárában.
int main(){ return 1/0;}
ez a program elindítja a fő funkciót, és egész számot (számot) ad vissza. Azonban az 1-et nullával osztja, ami nem megengedett, és összeomlik. A következő lépés a kis hibás programunk összeállítása.
az instabil kis programunk
még a fordító is azt mutatja, hogy a programunk komoly problémát tartalmaz, és figyelmeztetést jelenít meg róla. Most nézzük meg, hogy ez a helyzet.
szép ütközés!
ebből az egyetlen sorból valójában megtanulhatunk néhány dolgot. Először is, hogy kilép egy kivétellel, kifejezetten a lebegőpontokra hivatkozva. Ez egy decimális számformátum a programok számára, tehát azt jelezheti, hogy valami történt matematika közben. Egy másik következtetés az, hogy a mag dömpingelt a végén lévő (mag dömpingelt) kiegészítés miatt. Ha a maglerakókat letiltanák, ez nem jelenik meg.
nagyszerű, tehát ezzel a fenti összeomlással most egy dömpingelt fájlunk van, igaz? Nem egészen. A Linux disztribúciótól függően előfordulhat, hogy a dolgok nem olyan egyszerűek, mint amilyennek látszik. Minden disztribúció eltérően foglalkozik a core dump-okkal és az alapértelmezett beállításokkal. A legújabb Linux disztribúciók is használják a systemd-t, és a szabályok kissé megváltoztak ezzel is. A konfigurációtól függően előfordulhat, hogy meg kell keresnie az alapvető hulladéklerakókat. Tehát itt van néhány tipp annak biztosítására, hogy minden megfelelően legyen konfigurálva.
2.lehetőség: futó folyamat megölése
tesztprogram használata helyett egy meglévő folyamatot is leállíthat. Ez a SIGSEGV használatával történik, amely a szegmentálás megsértésének rövidítése, valamint szegmentációs hiba.
kill -s SIGSEGV PID
ha a PID-t “$ $ ” – ra cseréli, az aktuális program (valószínűleg a shell) összeomlik. Mindent a tudományért, igaz?
3.lehetőség: a gdb használata
ha telepítve van a fejlesztő hibakereső eszköze gdb, akkor csatoljon egy választott folyamathoz annak folyamatazonosítójával (PID).
gdb -p 1234
ezután a gdb parancssorában generálja a core dump-ot a generate-core-file utasítás meghívásával. A parancs használata után vissza kell adnia a kimenetet.
mentett corefile mag.1234
ellenőrizze az ulimit beállításait
az ulimit beállításai határozzák meg, hogy mi történhet EGY program összeomlásakor. Tehát biztonságos ezt először ellenőrizni, mind a root, mind a normál, nem privilegizált felhasználó számára.
ellenőrizze a kemény határértéket a maglerakókhoz:
ulimit -H -c
ellenőrizze a lágy korlátot is:
ulimit -S -c
ellenőrizze a magmintát
használja a / proc fájlrendszert az érték összegyűjtéséhez és ideiglenes módosításához a tesztelés során. Ha inkább a sysctl-t használja, akkor kérdezze meg a kernelt.core_pattern kulcs.
cat /proc/sys/kernel/core_pattern
lehet, hogy valami ilyesmit mutat:
|/usr/share/apport/apport %p %s %c %P
ebben az esetben az összeomlás az apport segédprogramba kerül. Tehát ez azt jelenti, hogy az összeomlásokat az Apport fogja elemezni. Általában az összeomlások a /var/crash könyvtárban találhatók, de lehetnek a /var/spool vagy a /var/lib/systemd/coredump más Linux disztribúciókban is.
ellenőrizze a naplót (systemd)
esetünkben a journalctl mutatja az összeomlást, tehát ez a kezdet.
miután ellenőrizte ezeket a beállításokat, képesnek kell lennie egy szép core dump létrehozására.
következtetés
a Maglerakók hasznosak lehetnek a hibaelhárításhoz, de katasztrófa az érzékeny adatok kiszivárogtatásához. Tiltsa le a központi lerakókat, ha lehetséges, és csak akkor engedélyezze őket, ha valóban szükség van rá. Ebben az esetben ellenőrizze, hogy a fájlok biztonságosan vannak-e tárolva, így a normál felhasználók nem láthatják az adatokat. Függetlenül attól, hogy milyen döntést hozott, mindig ellenőrizze, hogy a konfiguráció pontosan úgy működik-e, ahogy azt elvárja.