Unix-alapok

A lap jelenlegi, 2017. június 21., 12:38-kori változata

A Unix:

• Többfelhasználós (multiuser)
• Többfeladatos (multitaszking)
• Hálózati (network)

operációs rendszer (operating system). De ezt úgyis tudtuk.

Egy csomó minden mást is tudunk, úgyhogy koncentráljunk inkább olyasmire, amit talán nem, vagy nem annyira pontosan.

[szerkesztés] 1 Processz állapottere

Ezek a processz valamilyen értelemben vett "tulajdonságai"; a döntő részüket a processz által indított gyermekfolyamatok öröklik.

• UID
• GID
• supplementary group memberships
• effektív UID (pl. setuid bit miatt lehet más)
• effektív GID (pl. setgid bit miatt lehet más)
• current working directory (cwd)
• filedeszkriptorok
  • Ezeknek része a pozíció-mutató is
• környezeti változók (environment variables)
• PGID
  • kill -SIGNAL -PGID az egész process groupnak elküldi a signalt
• scheduler
• niceness (Linuxon újabban külön ionice is)
• resource limits
• root directory (chroot esetén változhat)
• umask
• capability-k
• Linuxon újabban: namespace (külön fs-, hálózati-, processz-, esetleg IPC-)
• Linuxon újabban: control groupok (lehetséges házi feladat)
• stb.

[szerkesztés] 2 Capability-k

(Lehetséges házi feladat: hogy állunk ezen a fronton ma?)

• A root jogosultságainak szétparticionálása kisebb jogosultság-csomagokra, amikkel egy-egy thread külön-külön is rendelkezhet. Pl:
  • CAP_DAC_OVERRIDE: fájlrendszer-jogok figyelmen kívül hagyása;
  • CAP_KILL: nemcsak saját processznek küldhet signalt;
  • CAP_MKNOD: hozhat létre device node-ot a fájlrendszerben;
  • CAP_NET_BIND_SERVICE: bind()-olhat 1024 alatti portra;
  • CAP_SETUID: válthat user ID-t;
  • CAP_SYS_BOOT: újraindíthatja a gépet;
  • stb. (több tucat van)
• Majd egyszercsak rendesen működni fog, és akkor jó lesz. :) Szerencsére talán már belátható időn belül.
• A 2.6.24-es kernel óta elvileg a fájlrendszerben is adhatók capabilityk a programoknak, kb. mint a setuid bit. Mindössze kb. 10 évet késett ez a fícsör.

[szerkesztés] 2.1 Capabilityk a processzekben/threadekben

• Minden threadhez három capability-halmaz tartozik:
  • Permitted ("megengedett"): A thread által birtokolható, örökíthető capabilityk halmaza. Ami nincs benne, azt az adott thread sehogy sem tudja megszerezni (kivéve, ha új binárist tölt magára exec()-kel, és azon pl. setuid bit volt).
    • 2.6.24 előtt a CAP_SETPCAP-pel rendelkező processz bármelyik másik processz permitted készletében állítgathatta azokat a capabilityket, amik a saját permitted készletében megvoltak.
  • Inheritable ("örökíthető"): Amit a thread ebbe rak a permittedből, az lesz az általa exec() hívással indított új folyamat permitted készlete.
  • Effective ("hatásos"): ezeket szeretnénk éppen használni. A kernel a jogosultságellenőrzések során ezt nézi.
• A processz a capset() hívással viszonylag szabadon állítgathatja a két utóbbi halmaz tartalmát (de csak a permitted készletben levő capabilitykkel gazdálkodhat).
• fork() során az új processz a szülő capability-készleteit örökli.

[szerkesztés] 2.2 Capabilityk a fájlrendszerben

• A filerendszerben egy bővített attribútumban tárolódik, hogy az adott binárishoz milyen capability-halmazokat rendeltünk.
• Szintén három halmaz van:
  • Permitted: a bináris futtatásával létrejövő processz permitted-készlete kiegészül az itt felsorolt capabilitykkel.
  • Inheritable: ez egy maszk, amit a kernel az exec() hívás során ÉS-kapcsolatba hoz a hívó processz inheritable halmazával; az így kapott halmazhoz adódik hozzá az iménti permitted halmaz.
    • Ezzel korlátozható, hogy a bináris mit örökölhet a szülőjétől: pl. megoldható, hogy a /bin/sh ne örökölhessen CAP_DAC_OVERRIDE-ot és CAP_NET_BIND_SERIVCE-t. Ezzel egy csomó exploitot ki is heréltünk (persze ez csak látszatmegoldás lenne).
    • Jobban használható arra, hogy démonoktól eleve elvegyünk olyan capabilityket, amikre nincs szükségük: pl. a webszervernek nem kellhet CAP_MKNOD.
  • Effective: ez itt nem halmaz, hanem egy jelzőbit. Ha 1, az új processz permitted-készletében szereplő összes capability azonnal megjelenik az effective készletben is. Ha 0, akkor nem.
    • Buta programokhoz jó, amik nem tudják maguknak állítgatni az effective készletet akkor, amikor éppen kell.
      • Ez a jelenlegi programok kb. 99,9999%-ára igaz.

[szerkesztés] 2.3 capability bounding set

• Ez régebben egy olyan rendszerszintű maszk volt, ami korlátozta, milyen capabilityket rakhat egy thread a permittedből az inheritable készletébe (ha nem volt benne elve).
• A boot után a maszkban csak törölni lehetett a biteket, bebillenteni nem.
  • Ez a mechanizmus kevés valódi rendszerben volt igazán hasznos.
• Újabban a binárisok permitted-készletét is maszkolja (így a rendszerbe bárhogy bejuttatott CAP_DAC_OVERRIDE-os bináris sem juthat ehhez a capabilityhez, ha kivesszük a bounding setből).
• Még újabban (a 2.6.25 óta) már nem rendszer-, hanem szálszintű maszkról van szó. Arra jó, hogy korlátozhatjuk vele, a szülő capabilityjei közül melyek birtokába juthat egy gyermekfolyamat (egy új program) egy exec() során. Tehát ha pl. shellt hívunk a webszerverből, megakadályozhatjuk, hogy örökölje a CAP_NET_BIND_SERVICE-t.
  • A szál, ha van CAP_SETPCAP capabilityje, törölhet biteket a maszkból.
  • A maszk fork() és exec() során is öröklődik a gyermekfolyamatra.
• Vannak még ezzel kapcsolatos finomságok; l. man 7 capabilities

[szerkesztés] 2.4 Capabilityk használhatósága

• Egyelőre nem az igazi a sok kompatibilitási megoldás miatt, pl:
  • sajnos a 0-ás UID-val futó processzek exec() után is teljes capability-halmazt kapnak.
    • 2.6.26 óta nem feltétlenül; l. capabilities(7), "securebits".
  • Setuid root binárisok szintén.
  • Teljes root->nemroot uidváltás esetén a permitted és az effective halmaz törlődik.
  • root->nemroot EUID-váltás esetén a kernel törli az effective halmazt.
  • nemroot->root EUID-váltás esetén a kernel a permitted halmazt az effective halmazra másolja.
    • A 2.6.26-ban javítottak ezen, az okos programok (az összes program 0,0001%-a) már alighanem tudnák normálisan használni a capabilityket.

[szerkesztés] 3 Signalok

• Aszinkron jelzések processzek között.
  • A címzett nem tudja, kitől kapja a signalt.
• Lehet hozzájuk handlereket regisztrálni
  • Handler nélkül öt alapakció egyikét eredményezik:
    1. Term (kilépés)
    2. Ign (semmi)
    3. Core (kilépés és coredump)
    4. Stop (felfüggesztés)
    5. Cont (folytatás, ha a processz fel volt függesztve)
  • Van alapértelmezés, hogy ezek közül melyiket, de a processz megváltoztathatja.
  • A signal disposition (hogy mi történjen egy adott signal hatására) a processz tulajdonsága, minden threadben ugyanaz.
• Az érdektelenek kimaszkolhatók, blokkolhatók (kivéve KILL és STOP).
  • A blokkolt signalok sorbaállnak, amíg a processz vagy szál meg nem szünteti a blokkolásukat.
  • A processz lekérdezheti, milyen sorbanálló signaljai vannak (sigpending()).
  • Egyféle signalból csak egy állhat sorba.
  • A sorbanálló signalok kézbesítési sorrendje nem specifikált.
• Signal címzettje lehet processz vagy szál (thread).
  • Ha többszálú processz kap signalt, a kernel az adott signalt éppen nem blokkoló szálak közül véletlenszerűen választja ki azt, amelyik megkapja.
• Kézbesítésük amúgy sem feltétlenül azonnali (pl. D állapotú processz nem kapja meg, l. később)
• A signal megkapásakor a program futása megszakad, és a vezérlés a handlerre kerül.
  • Signal handlert óvatosan kell írni, mert a program tetszőlegesen inkonzisztens állapotban lehet a handler indulásakor.
  • A POSIX szabvány specifikál néhány tucat könyvtári függvényt, amiket elvileg gond nélkül hívhatunk signal handlerből; a többinél vigyázni kell.
  • Signal érkezése rendszerhívást is megszakíthat; a hívás ebben az esetben EINTR hibakóddal tér vissza, de a processz kérheti, hogy ilyenkor a legutóbbi rendszerhívás automatikusan hívódjon újra a signal handler kilépése után (ennél igazából bonyolultabb, függ a hívás jellegétől is, itt nem megyünk bele, l. man 7 signal).
• Signal küldése
  • kill paranccsal
  • kill() rendszerhívással
  • sigqueue() rendszerhívással (l. a real-time signaloknál)
• Néhány gyakori signal:
  • HUP (HangUp)
    • Ha eltűnik a terminál (pl. a user bezárja az ablakot)
    • Daemonoknál gyakran: olvasd újra a configot
  • INT (Interrupt)
    • CTRL-C
  • QUIT
    • CTRL-\
  • ILL (Illegal instruction)
    • CPU-kivétel
    • súlyos program- vagy hardverhibára utal
  • KILL
    • Kilépteti a processzt, nem maszkolható
  • USR1
    • Nincs előre definiált jelentése, szabadon felhasználható
  • SEGV (Segmentation Violation)
    • "A program érvénytelen műveletet hajtott végre"
    • Tipikus okok:
      • Pointer rossz helyre mutat (pl. túlcímeztünk egy tömböt)
      • Valamit kértünk, nem sikerült, mégis használjuk (pl. nemlétező file-t próbáltunk megnyitni, és annak ellenére, hogy az open() hibát adott vissza, az érvénytelen filedescriptorból olvasni próbálunk)
    • Vagyis: programhiba
    • Lehet hardverhiba is
  • USR2
    • l. mint fent
  • PIPE ("broken pipe")
    • A pipe-unkat olvasó processz kilépett
  • ALRM (Alarm)
    • Időzítő lejárt
  • TERM (Terminate)
    • Default "lépj ki" signal
  • CHLD (Child exited)
    • Véget ért egy gyermekfolyamatunk
  • CONT (Continue)
    • Folytatódhat a végrehajtás STOP vagy TSTP után
  • STOP
    • Felfüggesztés, nem maszkolható
  • TSTP (Terminal stop)
    • Felfüggesztés CTRL-Z hatására
  • XCPU (CPU time exceeded)
    • Lejárt a megengedett CPU-idő
  • WINCH (Window changed)
    • Megváltozott a terminál mérete
• Létezik "real-time signal" is; a Linux 32 különbözőt támogat.
  • Nincs előre definiált jelentésük, arra használjuk, amire akarjuk.
  • Különlegességek:
    • Ugyanabból a real-time signalból egynél több is állhat sorba egyszerre.
    • A sigqueue() rendszerhívással adat is küldhető a signal mellé; a címzett ki tudja olvasni.
    • Ha sigqueue()-t használunk, a címzett megnézheti, milyen UID-val és PID-val futott a küldő-processz.
    • A kézbesítés sorrendje garantált. Először a signalok sorszáma szerinti növekvő sorrendben, és ha ez nem egyértelmű, akkor a sorbaállítás ideje szerinti növekvő sorrendben kézbesülnek.
    • A 2.6.8-as kernel óta userenkénti rlimit szabályozza, hány signal állhat sorba.
      • Az rlimit a processz állapotteréhez tartozik; több azonos UID-val futó processz limitje különbözhet. Az ellenőrzés a sigqueue() meghívásakor történik, és a kernel a hívó processz limitjét hasonlítja össze az adott user által már sorbaállított signalok számával.

[szerkesztés] 4 Processzek állapotai

Pl. a ps(1) outputjában látszanak:

% ps axu
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
[...]
korn      1842  0.0  0.1   4932  2592 ?        Ds   Sep07   0:23 SCREEN -D
korn     17670  0.0  0.0   4896   948 pts/0    R+   20:55   0:00 ps axu
[...]

• D: I/O-ra vár (itt alighanem épp a read() vagy a write() rendszerhívásban)
• R: fut vagy futásra kész
• S: vár (ilyenkor kaphat signalt)
• T: fel van függesztve
• Z: "zombie" - véget ért, de a szülője még nem olvasta ki a visszatérési értékét a wait() vagy a waitpid() rendszerhívással

Egyéb flagek:

• <: negatív nice (több processzoridőt kap)
• N: pozitív nice (kevesebb processzoridőt kap)
• s: session leader (számunkra most nincs jelentősége)
• l: többszálú
• +: előtérben van

[szerkesztés] 5 Ajánlott irodalom

Ezeket részben hallgatók írták egy másik tárgy óráin elhangzottak alapján, úgyhogy lehetnek bennük tévedések:

• 2004. őszi "alapozólabor" első gyakorlatának óravázlata
• 2005. tavaszi "alapozólabor" első gyakorlatának óravázlata
• 2005. őszi "alapozólabor" első gyakorlatának óravázlata
• 2006. tavaszi "alapozólabor" első gyakorlatának óravázlata

Ezek megbízhatóbbak, de csak a signalokról van szó bennük:

• man 7 signal (különösen a realtime signalokról szóló rész tanulságos)
• man 2 kill (magyarul)
• man 1 kill (magyarul)

A processzek lehetséges állapotairól:

• man ps

A process groupokról:

• http://en.wikipedia.org/wiki/Process_group
• Job Control (Ez kicsit részletesebb.)

Az egész TTY-rendszerről, job controlról, kapcsolódó signalokról részletesen:

• The TTY demystified

[szerkesztés] 6 Potenciális zh-kérdések

• Soroljon fel legalább tíz olyan állapotváltozót (az állapottér elemét), amelyet egy unixos gyermekfolyamat örököl a szülőjétől! Melyik micsoda, mit jelent, mit határoz meg?
• Mi a process group?
• A processzek szempontjából mit jelent az, hogy egy felhasználó tagja egy csoportnak?
• Mit jelent a kiegészítő csoporttagság (supplementary group membership)?
• Hogyan jut érvényre az, hogy egy felhasználó tagja egy csoportnak? Mi történik a felhasználó futó folyamataival, ha a felhasználó egy csoporttagságát megszüntetjük? És ha megváltoztatjuk a UID-ját?