Eddigi ZH-kérdések

Az alábbiakban leírom az eddig szerepelt zh-kérdéseket, a hozzájuk tartozó helyes válaszokat (ezeket a zh-ban elvárt minimális részletességnél szabatosabban kifejtve), és esetleg néhány, a hallgatók által írt választ, kommentárokkal. Az olvashatatlan szavakat "????" jelöli; a megtippelt, de nem jól olvasható szavakat "????megtippelt_szó????". A helyes válaszokban zárójelben szereplő mondatok csak kiegészítik a választ, nem elvárás, hogy a zh-ban is leírjátok őket.

A megadott pontszámok a zh-ban szereplő pontszámok; elvileg a kérdések relatív nehézségén és fontosságán kívül azt is hivatottak tükrözni, mennyire részletes választ várok el. A későbbiekben a tapasztalatok alapján ezek a pontszámok módosulhatnak, és egy itt leírt négypontos kérdés legközelebb szerepelhet pl. hatpontosként.

Sajnos a zh-k helyesírása és magyarsága több esetben hagyott kívánnivalót maga után. Szerintem helytelenül írni igénytelenség. Ezzel persze nem kötelező egyetérteni, és a pontozásnál sem vettem figyelembe a nem értelemzavaró hibákat, de azért próbáljatok erre is odafigyelni.

1 Unix-alapok

• Mit jelent a kiegészítő csoporttagság (supplementary group membership)? (4 pont)

Helyes válasz:

Egy unixos felhasználónak van egy felhasználó-azonosítója (UID) és egy csoport-azonosítója (GID), vagyis egy csoportnak mindenképpen tagja. Ez az elsődleges csoporttagság. Emellett a felhasználó más csoportoknak is tagja lehet; a /etc/group fájlban (vagy az ezt helyettesítő címtárban/adatbázisban) fel van sorolva, hogy az egyes csoportoknak mely felhasználók a tagjaik. Amikor a felhasználó belép, az őt beléptető processz a login shell elindítása előtt belép ezekbe a csoportokba is, és ezeket a csoporttagságokat a shell örökli tőle. Így tehát igazából a kiegészítő csoporttagságok halmaza a unixos processz egyik állapotváltozója.

Ha egy processz tagja egy csoportnak, akkor vonatkoznak rá a fájlrendszerben a csoportra vonatkozó jogosultságbitek.

Egy válasz a zh-ból (betű szerint):

az amikor egy felhasználó a /etc/group fileban nem csak a saját group-jában szerepel, hanem egyibb csoportokban is pl: audio,floppy. Így több fájlhoz is hozzáférhet a filok nála groupra vonatkozó rwx csoportnál ezeket a csoport tagságokat is figyelembe veszi. csak a változtatás után indított process-ekre igaz, hiszen igazából nem a felh.nak, hanem a process-eknek van UID-jük és GID-jük.

Kommentár: A válasz 2,5 pontot ér; több súlyos tévedést is tartalmaz, de ezekre szerencsére részben nem vonatkozott a kérdés.

A /etc/group file-ban az egyes csoportok tagjai vannak felsorolva, nem az, hogy az egyes felhasználók mely csoportoknak tagjai (ha így lenne, az utolsó csoporttag törlésével elvesztenénk a csoportot is). A /etc/group amúgy csak a kiegészítő csoporttagságokat tartalmazza, a felhasználó a GID-jához tartozó csoportnál alapértelmezés szerint nincs felsorolva.

Ha egy felhasználót berakunk egy új csoportba, akkor az általa indított új processzek nem kapják meg automatikusan az új csoporttagságot, hiszen a csoporttagságokat a szülőfolyamatuktól öröklik, az pedig nem rendelkezett ezzel a csoporttagsággal. Az új csoporttagságra új login session indításával vagy a newgrp segítségével lehet ténylegesen szert tenni.

2 IP-alapok

• Mire való az ARP? Milyen üzenetei vannak? (5 pont)

Helyes válasz:

Az ARP arra való, hogy az egy fizikai hálózaton levő IP-vel kommunikálni vágyó számítógépek fel tudják deríteni egymás fizikai rétegbeli címét. Etherneten és az Ethernetre elegendően hasonlító hálózatokban használják.

Két üzenete van: a kérdés ("who-has 1.2.3.4 tell 1.2.3.1") és a válasz ("1.2.3.4 is-at 00:f0:0d:d0:0d:00").

(Az ARP nem IP-csomag, így nincs IP-fejléce.)

Adatkapcsolati szinten a kérdés forráscíme annak az állomásnak a címe, amely a választ tudni szeretné; a célcím a broadcast.

A válasz forráscíme annak az állomásnak a címe, amely tudja a választ (ez nem feltétlenül a keresett állomás); a célcím a kérdező állomás címe.

(Az ARP-kérdést elvileg nem muszáj broadcastként feltenni, de ez a leggyakoribb.)

(Az ARP elvileg többféle Ethernet felett szállítható protokollt is támogat.)

(Az ARP-kérdés a payloadban is tartalmazza a kérdező hardvercímét, és igazából erre a címre kell küldeni a választ.)

(Elvileg a RARP-üzenetek is az ARP-hez tartoznak, de nemigen használ ilyet senki.)

(A "who-has" és az "is-at" nevek a tcpdumphoz fűződnek, a szabvány kevésbé szemléletes neveken emlegeti az üzeneteket.)

Egy válasz a zh-ból (betű szerint):

ARP

IP->MAC megfeleltetés

who-has src mac: saját valós mac

dst mac: FF:FF:FF:FF:FF:FF

src IP: saját IP

dst IP: a cél IP-je

is-at src mac: cél saját mac-je

dst mac: saját mac

src IP: cél IP-je

dst IP: saját IP

Kommentár: a válasz 2,5 pontot ér. Súlyos hiba, hogy az ARP-t IP fölötti protokollként képzeli el. Nem írja le továbbá a who-has és az is-at üzenetek tartalmát.

3 DNS

• Mekkora legyen egy rekord TTL-je? Miért éppen annyi? Miért baj, ha túl nagy, és miért baj, ha túl kicsi? (6 pont)

Helyes válasz:

Egy rekord TTL-je akkora legyen, hogy lehetőleg éppen a következő tervezett módosítás előtt járjon le. Ha nem tudjuk, mikor lesz a következő módosítás, akkor akkora legyen, amennyi ideig vállalható, hogy kliensek esetleg még a rekord régi tartalma szerint járnak el; tehát pl. az előző címén keresik a webszervert.

Ökölszabály: várhatóan lassan változó rekordok TTL-je legyen néhány órás (vagy akár néhány napos). Nem valószínű, hogy gyakran változna pl. egy domain MX-ének a neve, tehát az MX rekord TTL-je akár egy hét is lehet; a névhez tartozó IP viszont talán megváltozhat "váratlanul" (pl. mert átmegyünk másik hosting-szolgáltatóhoz, vagy mert DNS alapú failovert valósítottunk meg), így ennek a TTL-je lehet jóval alacsonyabb (néhány óra, vagy failover esetén akár csak öt perc).

Ha a TTL túl nagy, az azért baj, mert akkor a rekord tartalmának megváltoztatása után sokáig lehetnek olyan kliensek, akik a rekordnak még az előző tartalmát ismerik, és rossz gépnek próbálják kézbesíteni a leveleinket, rossz DNS-szervertől érdeklődnek a hosztneveinkről s.í.t. Ha az ebből adódó problémákat el akarjuk kerülni, akkor a rekord megváltoztatása után még legalább a TTL-ben megadott ideig mindkét címen (az újon és a régin) nyújtanunk kell a szolgáltatást.

Ha a TTL túl kicsi, az azért baj, mert a kliensek csak rövid ideig cache-elik a rekordok tartalmát és feleslegesen gyakran fordulnak a DNS-szerverünkhöz; így a szervernek megnő a terhelése, a kliensek pedig lelassulhatnak (mert pl. két kattintás között megint le kell kérdezni a webszerver IP-címét).

(Van olyan DNS-szerver, pl. a djbdns, amely tervezett DNS-változtatásokat úgy támogat, hogy a megváltoztatandó rekord TTL-jét minden válaszhoz egyenként kiszámítja úgy, hogy éppen a tervezett változtatás pillanatában járjon le.)

Egy válasz a zh-ból (betű szerint):

Általában néhány óra legyen egy DNS rekord TTL-je, ez szabja meg, hogy a kliens ezt meddit cachelheti. Ha túl nagy a TTL azzal az a baj, hogy lehet, hogy a rekord valami miatt megváltozott és erről csak nagyon későn a TTL lejárta után értesül a kliens. Ezért szolgáltatás kiesést okozhat.

Ha túl kicsi azzal az a baj, hogy folyton lekérdezi a kliens ezzel megterheli a DNS szervereket. Ezért optimális a pár óra. Ha nagyobb karbantartást szeretnénk végezni, akkor ????érdemes???? a TTL-t ????1-re 1s-ra???? ????állítani????, megvárni míg a régi ????lejár???? majd ????utána???? elvégezni a karbantartást, ezzel gyakorlatilag 0 lesz a szolgáltatás kiesés.

Kommentár: A válasz 4 pontot ér.

Alapvetően jó, de nem írja le, hogy a néhány óra egy olyan ökölszabály, amitől bizonyos esetekben érdemes eltérni (l. a DNS-alapú failover, ill. a szinte biztosan hosszú életű rekordok esetét).

Csak az ökölszabályt írja le, nem próbálja mérnöki módon megfogalmazni, mi alapján döntsük el, mennyi legyen a TTL.

Nem említi, hogy a szolgáltatáskiesés elkerülhető, ha a régi címen is fenntartjuk a szolgáltatást a TTL lejártáig (ami persze költséges és/vagy lehetetlen lehet).

Nem említi, hogy kliensoldalon is eredményezhet lassulást a túl kicsi TTL.

---

• Mi a baj a glueless delegációkkal? Ugyanakkor mi a jó bennük? (10 pont)

Helyes válasz:

Egy delegáció kétféleképpen lehet glueless. Az egyik eset az, amikor olyan szervernek delegálunk egy domaint, amelynek a nevére nem vagyunk autoritatívak (pl. mondjuk a .hu-ra autoritatív szerver az ns.foo.com-nak delegálja a foo.hu domaint). Ebben az esetben a delegáló szerver nem adhatja át glue-ként a delegációban szereplő szerver A rekordját a kliensnek, mivel nincs joga nyilatkozni arról a domainről, amelybe az a szerver tartozik; a .hu nameserver nem autoritatív a .com-ra (elvileg lehetne autoritatív arra is, de ez most mindegy).

A másik eset az, amikor a delegáló szerver adatbázisába szándékosan nem vesszük fel az alárendelt szerver A rekordját annak ellenére, hogy megtehetnénk (mert autoritatívak vagyunk a nevére). Ez elég nagy marhaságnak tűnik; remélem, a valóságban senki nem csinál ilyet.

A baj a glueless delegációval az, hogy a kliensnek újra kell kezdenie a feloldást, esetleg a gyökértől, hogy megtudja a megkérdezendő szerver IP-címét; ha közben újabb glueless delegációval találkozik, akkor megint, s.í.t. Így nem biztos, hogy adható felső korlát egy feloldás memóriaigényére. Ráadásul a glueless-ség körbeérhet, és ebben az esetben a körben szereplő egyetlen domain sem oldható fel.

Pl. ha az a.com nameservere az ns.b.net, a b.net-é az ns.c.hu, a c.hu-é az ns.d.org, a d.org-é pedig az ns.a.com, akkor egyik domain sem elérhető, ha a delegációk glueless-ek, de mire ez kiderül, a rekurzív rezolver elpazarolt egy csomó időt és memóriát.

A glueless delegáció egyetlen "előnye" az, hogy a delegációval kapcsolatos NS rekordot tartalmazó zónába nem kell felvenni a delegációt kapó DNS-szerver A rekordját, így ezt a rekordot karbantartani sem kell, ha megváltozna (ehhez persze viszonylag bonyolult üzleti folyamatok tartozhatnak, úgyhogy nem feltétlenül egyszerű). Ez roppant kényelmes a delegációt végző szerver üzemeltetője számára, csak mindenki mással kitolás.

Hogy a mi domainjeinkre mutató delegációk gluelessek-e, azt mi magunk is befolyásolhatjuk; ha ügyelünk arra, hogy a domainre autoritatív szerver neve a domainen belül legyen (tehát a foo.com nameserverének neve a foo.com domainbe tartozzon, mondjuk ns.foo.com vagy a.ns.foo.com), akkor adunk esélyt a glue-nak.

Egy válasz a zh-ból (betű szerint):

A DNS-szerver a kérdezőnek delegáláskor a glue-ban átadhatja egy a keresett domainnel azonos zónába eső nameserver IP címét. Ez jó, mert így nem kell külön feloldani a nameserver ????nevét????, növekszik a DNS hatékonysága. Pl. a pool-foobar.axelero.hu megkérdezi a .hu zónáért felelős nameservert, hogy mi a www.bme.hu IP címe. A szerver válaszol, hogy ő nem authoritatív, de kérdezze meg az ns.bme.hu-t. Ilyenkor a kliensnek fel kellene oldani az ns.bme.hu-t is, ezt azonban a nameserver átadhatja glue-ban. Ha pl. a www.bme.edu-t próbáljuk meg feloldani, és a .hu-ért felelős name servertől kapjuk meg az ns.bme.edu IP címét, azt nem hisszük el neki.

A glueless delegációk rontják a DNS hatékonyságát, jó bennük, hogy pl. minden további nélkül megváltoztathatjuk a name serverünk IP címért, mert mindig feloldásra kerül a neve. Ez az előny elenyésző, érdemes használni a glue-t.

Kommentár: a válasz 9 pontot ér. Hibák:

A .hu zónáért felelős szerver természetesen autoritatív minden, a .hu alatti névre, így a www.bme.hu-ra is. Nem azt válaszolja az erre vonatkozó kérdésre, hogy nem autoritatív (ilyen válasz a DNS-ben gyakorlatilag nem is lehetséges), hanem egy delegációt tartalmazó választ küld.

Ha a .hu zónáért felelős szerver egy másik, .hu alatti szervernek delegál egy zónát, akkor annak a címét illik is átadnia glue-ban, hiszen kitől kérdezhetnénk meg, ha a .hu szerverek nem mondják meg?

A válasz első fele részben redundáns volt; nem volt kérdés, mi a glue (de persze inkább írjatok többet, mint kevesebbet). Ugyanakkor ez a bevezető győzött meg arról, hogy a hallgató valószínűleg érti, miért rontja a glueless delegáció a DNS hatékonyságát, mert azt külön nem írta le.

---

• Mit jelent a DNS-ben a delegáció? Mondjon példát! (6 pont)

Helyes válasz:

Delegációnak - a kliens szemszögéből - azt nevezzük, amikor egy DNS-szerver válaszában nincs Answer section, csak olyan Authority section, amiben a kérdésben szereplő domainre, vagy egy a hierarchiában fölötte álló domainre vonatkozó NS rekordok vannak. Ebből a kliens megtudja, hogy melyik másik DNS-szervernek kell feltennie a kérdést a végső válasz reményében.

A DNS-adminisztrátor szemszögéből a delegáció az, amikor szubdomaint definiál, és ennek a karbantartását rábízza valaki másra: a szubdomainhez tartozó NS-rekordban megadott szerver üzemeltetőjére.

A DNS egésze szempontjából a delegáció az, ami hierarchikussá teszi a DNS-t, mint adatbázist. Elvileg a root szerverek minden névre autoritatívak, a valóságban azonban - a delegációnak köszönhetően - nem kell minden név összes rekordját ismerniük, hanem elegendő azt tudniuk, hogy a TLD-kre (top-level domainekre) mely szerverek autoritatívak; vagyis a TLD-ket delegálják azoknak a szervereknek, amelyek az egyes TLD-kre autoritatívak, s.í.t.

Példa: Ha valamelyik, a hu. zónára autoritatív szervertől megkérdezzük, mi a www.bme.hu domain A rekordja (ne feledjük, a DNS-ben minden domain, a "hosztnevek" is), a válaszban nem lesz Answer section (vagyis a keresett A rekord), de lesz olyan Authority section, amiben fel vannak sorolva a bme.hu domainre autoritatív szerverek (és lehet egy Additional section, amelyben ezek közül azoknak, amik szintén .hu alattiak - vagyis, véletlenül, az összesnek - benne lesz az A és/vagy AAAA rekordja is - ez a glue).

Példa az adminisztrátor szemszögéből: ha a hu. zónafájlba azt írjuk, hogy "bme.hu. IN NS ns.bme.hu.", akkor az ns.bme.hu-nak delegáltuk a bme.hu domainnel kapcsolatos kérdéseket.

Egy válasz a zh-ból (betű szerint):

Delegáció: ha csak azt mondjuk meg egy DNS-kérésre, hogy merre kell tovább tapogatózni a cím után.

Pl. ha a www.bme.hu keresésekor a *.hu-ra autoritatív DNS szerver címét kapjuk válaszként

Kommentár: a válasz 5 pontot ér. A delegációt, mint láttuk, többféle szemszögből meg lehet közelíteni; a hallgató a kliens oldaláról közelítette meg, és a lényeges információk többségét leírta. Hiányzik azonban, hogy kitől (ti. a root szervertől) fogjuk megkapni a .hu-ra autoritatív szerverek nevét (a címüket csak glue-ként). Ezek a pontatlanságok önmagukban nem súlyosak, de összesen indokolják egy pont levonását.

4 Az SMTP működése

• Milyen módokon (nem mi alapján!) utasíthat el egy SMTP-szerver egy nem kívánt levelet? Melyiknek mi a következménye a levél későbbi sorsát illetően? (6 pont)

Helyes válasz:

- A TCP-kapcsolat elutasításával. A kliens (ha valódi levelezőszerver) egy darabig újra meg fogja kísérelni kézbesíteni a levelet; ha hosszú ideig nem sikerül, feladja, és hibaüzenetet küld a feladónak.

- A TCP-kapcsolat bontásával az SMTP-kapcsolat során, a levél átvétele előtt. A kliens (ha valódi levelezőszerver) egy darabig újra meg fogja kísérelni kézbesíteni a levelet; ha hosszú ideig nem sikerül, feladja, és hibaüzenetet küld a feladónak.

- Kliensoldali időtúllépés szándékos kiprovokálásával az SMTP-kapcsolat során (egyszerűen sokáig nem válaszol). A kliens (ha valódi levelezőszerver) egy darabig újra meg fogja kísérelni kézbesíteni a levelet; ha hosszú ideig nem sikerül, feladja, és hibaüzenetet küld a feladónak.

- Az SMTP-tranzakció során, "ideiglenes" (négyessel kezdődő) válaszkóddal. A kliens (ha valódi levelezőszerver) egy darabig újra meg fogja kísérelni kézbesíteni a levelet; ha hosszú ideig nem sikerül, feladja, és hibaüzenetet küld a feladónak.

- Az SMTP-tranzakció során, "végleges" (ötössel kezdődő) válaszkóddal. A kliens a levelet kézbesíthetetlennek tekinti és hibaüznetet küld a feladónak.

- (Minden ettől eltérő viselkedés - pl. ha átveszi a levelet, de nem kézbesíti, csak hibaüzenetet küld a feladónak, vagy még azt sem - a levél elfogadásának minősül az SMTP kontextusában.)

Egy válasz a zh-ból (betű szerint):

- nem épít fel a másik szerverrel TCP kapcsolatot

következmény: ha spammer vsz. nem próbálkozik újra ma már ez sajnos nem igaz.

ha nem spammer akkor újra próbálkozik kicsit lelassítja a valódi leevlek kézbesítését

- átmenetileg vissza utasítja

köv: 4xy hibakóddal átmenetileg visszautasitja a levél átvételét, késöbb lehet próbálkozni

- permanensen visszautasítja

köv: 5xy hibakóddal végérvényesen visszautasítja a levél átvételét, nem érdemes többszörprobálkozni

Kommentár: a válasz 6 pontot ér annak ellenére, hogy keveri a következményeket a módszerrekkel (jóra gondolt, de rosszat írt). Felsorolta a három legelterjedtebb módszert. Kicsit hiányzik, hogy mi történik, ha a későbbi próbálkozások is hasonlóan sikertelenek, de az SMTP-hibaüzenetek annyira közismertek, hogy bizonyára mindenki tudja, hogy ilyenkor hibaüzenet jön.

5 A HTTP működése

• Milyen problémával kell számolnunk, ha HTTP virtualhostingot használunk, és SSL-re is szükségünk van? Milyen megoldásai vannak a problémának? (6 pont)

Helyes válasz:

A HTTP virtualhosting működési elve az, hogy a HTTP Host: fejlécében megmondjuk a webszervernek, melyik virtuális szerver címterében kell értelmezni a kérésben átadott elérési utat és fájlnevet. Ha HTTPS-t használunk, akkor a böngésző és a webszerver közötti TCP-kapcsolat felépülése után először az SSL handshake-re kerül sor; ennek során a böngésző hitelesíti a szervert, és többek között azt is ellenőrzi, hogy a szerver tanúsítványa az URL-ben szereplő hosztnévre szól-e.

A gond az, hogy a szerver ebben a pillanatban még nem tudja, hogy mi az URL, így, ha virtuális hosztokat használunk, nem tudja eldönteni, melyik virtuális hoszt tanúsítványával hitelesítse magát a böngésző felé; ha nem a jót választja, a böngésző hibaüzenetet ad (vagy az alkalmazásszintű proxy megtagadja a webszájthoz való hozzáférést). A szerver csak az SSL-handshake után, a HTTP-tranzakcióból tudja meg (a Host: fejlécből), hogy melyik virtualhostra kíváncsi a kliens.

Két megoldás van: az egyik az, hogy minden HTTPS-es virtualhostos külön IP:port páron futtatunk, így a szerver abból, hogy melyik IP:portra jött kapcsolatkérés, meg tudja állapítani, melyik virtualhostot szólítják meg éppen, és így azt is tudja, melyik tanúsítvánnyal kell hitelesítenie magát.

A másik megoldást csak akkor használhatjuk, ha minden virtualhostunk ugyanabba a domainbe tartozik, és a hitelesítő hatóságunk (CA, certificate authority) hajlandó nekünk joker-tanúsítványt adni erre a domainre; ekkor a tanúsítvány elvileg minden, az adott domainbe tartozó konkrét hosztnévre érvényes lesz, tehát a szerver nem kerül olyan dilemma elé, hogy több tanúsítvány közül kellene választania, vagyis az összes virtualhost maradhat ugyanazon az IP:port páron, hanem hitelesítheti magát azzal az eggyel, ami van. A módszer hátránya, hogy nem minden CA ad ki - és nem minden böngésző fogadja el - a joker-tanúsítványt.

Egy válasz a zh-ból (betű szerint):

Az a probléma, hogy a kliens elküldi a HTTP-kérésben a kért weboldal címét, ekkorra azonban már túl kéne esni az SSL-handshake-en, amihez kéne tudni a kért oldal címét (hogy melyikhez tartozó tanúsítványt használjuk). Megoldás:

1. különböző portra kell tenni a virtuális HTTPS-szervereket és port alapján tudjuk, melyik cert. kell

2. a domain-re vonatkozó cert. kell

Kommentár: A válasz 5 pontot ér. Fél pont levonás jár azért, mert nem fejti ki, mi "a domain" (impliciten feltételezi, hogy minden virtualhost ugyanabba a domainbe tartozik), és másik fél pont levonás azért, mert nemcsak külön portra, hanem külön IP-re is tehetjük az egyes virtuális szervereket; az IP:port párnak kell különböznie.

6 Filerendszerek

• Fájlrendszerek kontextusában mi a fork? (3 pont)

Helyes válasz:

Ha a fájlrendszer lehetővé teszi, hogy egyetlen fájlhoz több, a fájlrendszer szintjén elkülönülő adatterület is tartozzon, akkor ezen adatterületek mindegyike egy-egy fork.

(A fájl érdemi tartalma a default fork; egyéb forkok tartalmazhatnak pl. bővített attribútumokat, POSIX ACL-eket, kép thumbnailjét, dokumentum meta-adatait stb.)

Egy válasz a zh-ból (betű szerint):

egy file-t több részletben több helyen tárolunk az FS-en ilyen lehet pl. mp3 ID3 tagjei, képek tumbnailjei, extended attribute-umok

Kommentár: A válasz 2,5 pontot ér, mert sajnos pontatlanul fogalmaz. Mit jelent az, hogy "több részletben, több helyen tároljuk"? A fragmentálódott fájlokat is több részletben, több helyen tároljuk, mégsem állnak szükségszerűen több forkból. A válasz igazából nem definiálta a forkot, csak mondott rá példát, amiből az ID3 tag ráadásul nem is jó példa, mert az szükségszerűen a fájl elsődleges adatterületének a része (persze az ID3 tagben található adatokat tarthatnánk egy - vagy egy-egy - forkban).

---

• Mire jók a POSIX ACL-ek? Mondjon példát olyan jogosultságrendszerre, ami POSIX ACL-ekkel leírható, de hagyományos unixos jogosultságokkal nem! Bónuszkérdés: olyanra is tud példát, ami POSIX ACL-ekkel sem írható le? (10 pont)

Helyes válasz:

A POSIX ACL-ek egy olyan DAC (discretionary access control) mechanizmust valósítanak meg, amelynek segítségével csoportokra és felhasználókra lebontva megadhatjuk, hogy az adott inode-ra (fájlra, könyvtárra) kinek legyen olvasási, írási ill. végrehajtási joga. Az ún. "effective rights mask" segítségével valamennyi ACL-ből kimaszkolhatók bizonyos bitek (tehát pl. egyszerűen megvonható mindenkitől az írási jog akkor is, ha a saját ACL-je szerint van neki, és a mask újbóli módosításával visszaadható).

(Az ACL az Access Control List rövidítése.)

Mivel a POSIX ACL DAC-mechanizmus, nem pedig MAC (mandatory access control), a felhasználók a saját fájljaikon átállíthatják az ACL-eket, vagyis rendszerszinten sajnos nem kényszeríthetők ki vele bizonyos jogok bizonyos könyvtárakon.

Példa olyan esetre, ami unixos jogosultságokkal nem írható le: olyan fájl, amire az olvasó csoportnak olvasási joga van, az író csoportnak írási és olvasási joga is van, és azoknak a felhasználóknak, akik nem tagjai ezek közül egyik csoportnak sem, sem írási, sem olvasási joga nincs. (POSIX ACL-ekkel ezt egyébként így adhatjuk meg: setfacl -m g:olvaso:r--,g:iro:rw-,o:--- file)

Példa olyan esetre, ami POSIX ACL-ekkel sem írható le: egy végrehajtható fájl az egyik csoport számára legyen setuid root, a másik csoport számára egyszerűen végrehajtható, de ne setuidos. Ez azért nem oldható meg POSIX ACL-ekkel, mert a POSIX ACL-ek csak az rwx biteket tartalmazzák, a setuid, setgid, sticky biteket nem.

Egy válasz a zh-ból (betű szerint):

ACL Access Control List. Bonyolultabb hozzáférési jogrendszer mint a hagyományos unixos jogosultságok.

Pl. AFS-nél az hogy az AFS szerver gyökerén belül van egy Private mappa, Public és Public_html. Itt azt kell megoldani, hogy a public_html-t csak a webszerver olvassa viszont a publicot ne. Tehát ha egy szolgáltatásnak akarunk jogokat megadni azt ACL-el érdemes megtenni.

Kommentár: A válasz 2 pontot ér. A leírt példa lehet jó is, de a válaszból ez sajnos nem derül ki, mivel sajnos érthetetlen - mit jelent az, hogy "a publicot ne"? A publicot ne olvashassa a webszerver, vagy a publicot ne csak a webszerver olvashassa? És milyen jogok legyenek a Private könyvtáron? A POSIX ACL-ek szemantikájáról sajnos egy szó sem esik.

7 Software RAID Linux alatt

• Mi a write-behind a linuxos softraid kontextusában, és mire jó? (5 pont)

Helyes válasz:

RAID1 esetén a tömb egyes elemein beállítható külön a write-mostly flag, és az egész tömbre a write-behind működés. A write-mostly hatása az, hogy az adott eszközről az md driver próbál nem olvasni, csak szinkronizálni rá; ez akkor jó, ha az adott eszköz lassú, mert így akkor csak az írást lassítja le, az olvasást nem. A write-behind-ot akkor tudjuk bekapcsolni, ha a tömbnek van write-intent bitmapje, és az a hatása, hogy a write-mostly-nak jelölt eszközökre aszinkron módon fog írni az md driver; ennek az az értelme, hogy ha pl. egy viszonylag lassú hálózati diszk is része a tömbnek, akkor annak a sebessége nem fogja vissza nagyon a teljes tömb írási teljesítőképességét, a tartalma mégis nagyjából szinkronban marad a tömb többi részével.

(Erre a kérdésre az a hallgató, akinek a zh-jában szerepelt, nem válaszolt.)

8 Logikai kötetkezelés

• Hogyan lehet az LVM segítségével online mentést nem támogató adatbázisról mégis kvázi-online mentést készíteni? (10 pont)

Helyes válasz:

1. Leállítjuk az adatbázist – ami az adatokat egy logikai köteten tárolja –, vagy legalábbis befagyasztjuk a tranzakciókat, hogy rövid időre konzisztens állapotban maradjanak a diszken tárolt adatok.

2. Készítünk egy pillanatfelvételt (LVM snapshotot) az adott logikai kötetről. Ez nagyon gyorsan megvan.

3. Az adatbázist újraindítjuk, vagy újra engedélyezzük az író tranzakciókat.

4. Ezután az LVM a snapshot copy-on-write szemantikájának köszönhetően, ha az adatbázisszoftver ír az eredeti kötetre, akkor a módosítandó adatoknak egy másolatát elhelyezi a snapshot-köteten, így biztosítva, hogy onnan mindig kiolvasható legyen a snapshot készítésekori állapot.

5. Ezután a kedvenc offline backup-megoldásunkkal lementjük a snapshot-kötetről az adatbázist.

Így megoldható, hogy az adatbázist ne kelljen annyi időre leállítani, ameddig az offline mentés tart, csak a snapshot létrehozásának idejére, ami max. tizedmásodperces nagyságrendű idő.

Egy válasz a zh-ból (betű szerint):

LVM-el lehet snapshotot ???? ez csak a ????változtatásokat???? ???? le mivel ez kell vissza????.

Kommentár: a válasz az olvashatatlan szavaktól függetlenül 1 pontot ér, mivel csak a snapshotot, mint kulcsfogalmat említi, a módszer részleteiről egyáltalán nem emlékezik meg.

---

• Legfeljebb mennyi helyet érdemes allokálni egy snapshot LV számára? Miért? (3 pont)

Helyes válasz:

Legfeljebb annyit, amekkora az eredeti LV (aminek a snapshotja), mégpedig azért, mert a snapshot csak azokat az adatokat tárolja, amelyek az eredeti köteten megváltoztak, ennek a tárolásához pedig nem lehet szükség több helyre, mint amekkora az eredeti kötet (x MiB-nyi adatban legfeljebb x MiB-nyi változás tud bekövetkezni).

Egy válasz a zh-ból (betű szerint):

Legfeljebb annyit, amekkora a volume, amiről a snapshot készül, ez általában sok, helyette elég annyi, amennyi változásra számítunk az adott volume-on a snapshot használata alatt (a volume változhat, de a snapshot megőrzi a volume eredeti állapotát, ha a snapshotot nem változtatjuk, így az eredeti állapotnak változáskor ki kell íródnia a snapshotra).

Kommentár: a válasz 3 pontot ér; az indoklás ugyan nem szabatos, de a kérdés szempontjából irreleváns kiegészítésből kiderül, hogy a hallgató érti, miről van szó.

9 A runit működése

• Mik az előnyei a runitnak a hagyományos System V inittel szemben? Mik a hátrányai? (12 pont)

Helyes válasz:

Előnyök:

A runit több egyszerű (ezért kisebb erőforrásigényű és várhatóan kevesebb hibát tartalmazó) programmal oldja meg azt, amit az init egy bonyolult programmal.

A bootfolyamat jelentősen felgyorsulhat, mert a szolgáltatások egyszerre indulnak el.

A szolgáltatások közötti függőségek kezelése kézimunkával megoldható (System V init esetén csak kísérletezni lehet vele, robusztus megoldás nincs).

Menedzseli is a szolgáltatásokat, nemcsak elindítja: újraindítja őket, ha leállnak; küldhetünk nekik signalokat; kapunk hozzájuk robusztus naplózást.

(Az inittel is lehet újrainduló szolgáltatást csinálni - "respawn" -, de az nem állítható le szelektíven.)

A szolgáltatások leállításához nem szükséges PID-k megtippelése; mivel a szolgáltatás szülőfolyamata nem lép ki, mindig tudjuk, milyen PID tartozik a szolgáltatáshoz.

A szolgáltatások egységes környezettel indulnak, attól függetlenül, hogy parancssorból indítjuk őket vagy a bootfolyamat során indulnak el.

Tetszőleges számú és nevű runlevelünk lehet.

Ezeket az előnyöket a felhasználók saját szolgáltatásainak is tudjuk biztosítani.

A szolgáltatásokat, ha akarjuk, kiemelt csoportok vagy felhasználók root jogok nélkül is menedzselhetik, akkor is, ha a szolgáltatás root jogokkal fut; ehhez csak a szolgáltatáshoz tartozó runsv-parancs-FIFO-t kell a megfelelő csoport vagy felhasználó számára írhatóvá tenni.

Könnyen le tudjuk kérdezni a szolgáltatásaink státuszát (fut, nem fut, próbál elindulni, mióta fut, mióta nem fut stb.).

Kapunk olyan eszközöket (elsősorban a chpst-t), amikkel egyszerűen beállíthatjuk a futtatandó szolgáltatás unixos állapotterét az elindítása előtt.

Runlevel-váltáskor (a previous symlink segítségével) könnyen nyomon követhetjük, leálltak-e már az előző runlevelben igen, de az újban nem futó szolgáltatások.

Hátrányok:

Általában nem kapunk kész run-scripteket a szolgáltatásokhoz, ezeket nekünk kell megírnunk; így valamivel több munka van a runittal, mint az inittel.

Nincs egységes mechanizmus a szolgáltatások konfigurációjának újraolvastatására (ami az initben a /etc/init.d/szolgáltatásneve reload).

Ha blokkolódik a naplózás, blokkolódik a szolgáltatás (ez elkerülhető, de akkor viszont lehet, hogy elvesznek naplóüzenetek).

Általában nem a runit az alapértelmezés, így a rá való áttéréshez szükséges idő hozzáadódik a telepítés időigényéhez.

(Feltehetően lehet még találni előnyöket és hátrányokat is.)

Egy válasz a zh-ból (betű szerint):

runit előnyei:

- egy dologgal foglalkozik egy parancs, nem sokkal mint az init

- ha egy folyamat megáll újra tudja indítani

- nem probléma, hogy melyik processznek kell a signált küldeni

- kicsik a programok

- gyors

runit hátrányai:

- nem használják a distribek default az init helyett

- a szolgáltatások elindításához nekünk kell megírni a scripteket

- kicsit trükközni kell a runlevel váltásnál, bár a runlevel váltást nem nagyon használják

Kommentár: a válasz 7 pontot ér, mivel hét valódi előnyt/hátrányt említ. A runlevel-váltásra vonatkozó megjegyzés nem állja meg a helyét; nem kell "trükközni" runlevel-váltáshoz, egyszerűen más a mechanizmus, mint az initben. Egy (opcionálisan két) symlink átállítása nem "trükközés" ahhoz képest, hogy kiadjuk a "telinit x" parancsot. A previous symlink nem szükséges a runlevel-váltáshoz a runitban, csak nekünk segítség, hogy nyomon követhessük az előző runlevelben igen, de az újban nem futó szolgáltatásaink státuszát. Az initben ezzel ekvivalens mechanizmus amúgy egyáltalán nincs.

---

• Milyen esetekben rotálja a logokat az svlogd? (6 pont)

Helyes válasz:

A következő három esetben:

1. a log mérete elérte a configban megadott számú bájtot.

2. a log életkora elérte a configban megadott számú másodpercet, és a log nem üres.

3. az svlogd processz ALRM signalt kap, és a log nem üres.

Egy válasz a zh-ból (betű szerint):

svlogd: - ha a megadott paramétereket elérték a logok (méret, darabszám, időtartam stb.); a konfigfile-ban állítható be

- ha manuálisan megkérjük erre szignállal

Kommentár: a válasz 4 pontot ér, mivel gondolkodáshiányra utaló dolgot tartalmaz: a logok darabszáma nem lehet a rotálás feltétele, hiszen a rotálás megnöveli a logok számát, tehát ha egyszer túlléptük a küszöböt, akkor folyamatosan rotálnunk kellene. Másfelől viszont a logok darabszámát csak a rotálás növeli meg, tehát ha csak darabszám alapján akarnánk rotálni, akkor sosem rotálnánk. Emellett a válasz nem tér ki arra, hogy üres logot az svlogd semmiképpen nem rotál.

10 Naplózás

• Mik az előnyei/hátrányai az UDP ill. a TCP fölötti hálózati naplózásnak? (4 pont)

Helyes válasz:

Mivel a TCP kapcsolatorientált, a naplózószerver elvileg túlterhelhető kapcsolatokkal.

Mivel a TCP-ben van torlódásvezérlés, elképzelhető, hogy a naplóüzeneteket író programok blokkolódnak arra várva, hogy a helyi üzenetpuffert hálózaton át üríteni lehessen; ha nem ezt várják meg, egy idő után megtelik a memória a pufferrel vagy elküldés nélkül el kell dobni üzeneteket.

A TCP-kapcsolatok szemantikájának megvalósítása növeli a naplózókliens összetettségét; kezelni kell pl., ha megszakad a hálózati kapcsolat.

Az UDP kapcsolatmentes, "fire and forget" jellegű. Emiatt kliensoldalon nem feltétlenül van visszajelzés arról, hogy egy üzenet elküldése sikeres volt-e, vagyis hálózati problémák esetén naplóüzenetek elveszhetnek útközben.

A torlódásvezérlés hiánya miatt elvileg előfordulhat, hogy az UDP-s naplóüzenetek telítik a hálózatot.

A TCP-kapcsolatok viszonylag egyszerűen biztonságossá tehetők SSL/TLS használatával; elterjedt, szabványos UDP fölötti alkalmazási rétegbeli titkosító-hitelesítő technológia nincs.

UDP-csomagot könnyebb hamisítani, mint TCP-t (amihez session spoofing is kell), így könnyebb hamis naplóüzenetet küldeni UDP-n.

(Erre a kérdésre az a hallgató, akinek a zh-jában szerepelt, nem válaszolt.)

11 Tűzfalak

• Hasonlítsa össze a DROP és a REJECT iptables-akció működését! Mikor és miért érdemes vagy lehet az egyiket vagy a másikat használni? Mondjon példákat! (6 pont)

Helyes válasz:

A DROP eldobja a csomagot; a REJECT szintén eldobja a csomagot, de erről értesíti a csomag feladóját egy ICMP-üzenettel vagy (választhatóan) egy TCP RST csomaggal. TCP RST csomagot értelemszerűen csak TCP-csomagra tudunk válaszolni; ICMP-csomagra pedig egyáltalán nem válaszolhatunk, nehogy visszacsatolt hurok képződhessen.

A REJECT előnye az, hogy a távoli gép megtudja, hogy a csomagja nem elveszett, hanem nem kértük, így esetleg nem próbálkozik feleslegesen újra (meg újra meg újra). Jó példa arra, amikor ez nekünk (a tűzfal üzemeltetőjének) is jó, az auth (ident) szolgáltatás; ha a 113-as TCP portra jövő kapcsolatokat egyszerűen eldobjuk, akkor olyankor, amikor bizonyos szolgáltatásokat (pl. IRC) próbálunk igénybe venni, ki kell várnunk, amíg a távoli szerver feladja a próbálkozásokat az auth porton; míg ha azonnal küldünk TCP RST-t, akkor az első próbálkozás után rájön, hogy nincs azon a porton semmi, és nem kell kivárnunk a félperces nagyságrendű timeoutot.

A REJECT hátránya ugyanakkor, hogy egyrészt elárulja, hogy az adott címen egyáltalán van számítógép, másrészt pedig forgalmat generál, ami felhasználható lehet DoS-támadáshoz. Ezért ügyelni kell arra, hogy a REJECT szabályaink által generált forgalmat rátalimitáljuk.

Másfelől viszont előnye a REJECTnek, hogy nem árulja el, hogy tűzfal védi a gépet: a védett szolgáltatások portjai úgy viselkednek, mintha csakugyan nem futna ott szolgáltatás, nem pedig úgy, mintha szűrnénk az oda irányuló forgalmat. Emellett "jólneveltség" is jelezni, hogy egy szolgáltatás nem elérhető.

A DROPot akkor célszerű használni, ha a bejövő csomag nyilvánvalóan ártó szándékú; pl. egy ismert spammer IP-jéről jövő SMTP-kapcsolatfelvétel. Ha küldünk neki TCP RST-t, azzal megkönnyítjük a dolgát, ha viszont csak eldobjuk a csomagját, akkor egy darabig még lekötjük az idejét, mert esetleg párszor még megpróbálja.

Egy válasz a zh-ból (betű szerint):

DROP: a csomagot eldobjuk, a küldőt nem értesítjük erről. Pl. támadások érzékelésekor célszerű (portscan esetében lelassítja a támadást, ki kell várnia a timeoutot a támadónak).

REJECT: a csomagot eldobjuk, a küldő kap erről értesítést. Ha szeretnénk, hogy a küldő értesüljön a csomag eldobásáról, ez a célszerű.

Kommentár: válasz csak 3 pontot ér, mivel:

- nem írja le, milyen értesítést küld a REJECT a feladónak;

- nem mond konkrét példát arra, hogy mikor jó REJECT-et használni;

- nem szükségszerűen igaz, hogy portscan esetén a támadónak bármit is ki kellene várnia: megteheti, hogy minden vizsgált portra párhuzamosan elküld egy, majd röviddel később még egy, majd még egy csomagot, aztán csak a beérkező válaszokkal foglalkozik; ahonnan nem jön válasz, arról pedig feltételezi, hogy nem elérhető/szűrve van.

12 A munin működése

• Milyen esetben érdemes COUNTER helyett DERIVE típusúnak definiálni egy adatot a munin (rrdtool) számára, és miért? (4 pont)

Helyes válasz:

(A COUNTER típusú adatról az rrdtool feltételezi, hogy monoton nő; tehát ha az értéke csökkent, akkor egy 32 vagy egy 64 bites számláló túlcsordult.)

(A DERIVE típusú adatnál az rrdtool nem feltételez monotonitást; a kiolvasott érték idő szerinti deriváltját ábrázolja, ami lehet negatív is.)

Akkor érdemes DERIVE-ot használni COUNTER helyett, ha:

- olyan számlálónk van, ami viszonylag gyakran resetelődik anélkül is, hogy túlcsordulna (pl. reboot miatt); de

- nem tudunk vagy akarunk konkrét felső korlátot megadni az általa számolt mennyiség növekedési rátájára (amit az rrdtool a grafikonban ábrázol); viszont

- zavarnak a grafikonokban az rrdtool által feltételezett túlcsordulásokat korrigálni hivatott 2³²-es tüskék; de

- az nem zavar minket, ha a számláló valódi túlcsordulásakor a grafikonban nem látunk semmit.

A DERIVE-hoz ilyenkor elég egy univerzális, 0-ás alsó korlátot megadni; a COUNTERnek viszont (ha pl. hálózati forgalomról van szó) minden gépen kellhet más korlát (pl. mert mindenhol más az upstream sávszélesség).

Egy válasz a zh-ból (betű szerint):

Ez két különböző számláló típus, akkor érdemes COUNTER helyett DERIVE-ot használni, ha a számláló nem növekedhet minden határon túl.

Kommentár: a válasz sajnos csak 1 pontot ér, mivel nem indokolja meg, hogy miért érdemes DERIVE-ot használni akkor, ha a "a számláló nem növekedhet minden határon túl", ez viszont önmagában érthetetlen. Az egy pont azért jár, mert a hallgató látszólag tisztában van azzal, hogy egyáltalán micsoda a COUNTER és a DERIVE.