szerkesztette: Iványi Péter March 8, 2010

Átírás

1 Kiszolgálók üzemeltetése szerkesztette: Iványi Péter March 8, 2010

2 2

3 Tartalomjegyzék 1 Bevezetés 7 2 Kezdeti beállítások Gép neve Root Hálózati beállítások DHCP konfigurálás Indítás és leállítás Boot manager MBR GRUB LILO Bootloader megkerülése Egyéb bootloader-ek Bootolás initrd Boot scriptek Leállítás Azonnali leállítás Leállítás adott időben A leállítás visszavonása Felhasználók és csoportok Alapok /etc/passwd file Az /etc/passwd file módosítása /etc/shadow file /etc/group file Elsődleges csoport /etc/gshadow file Csoportok hozzáadása Csoportok módosítása Csoportok törlése

4 4.9 Felhasználók létrehozása useradd parancs adduser parancs Amikor nincs segítség Felhasználók törlése Felhasználók módosítása Felhasználó és csoport adminisztráció Szabványos felhasználók és csoportok Korlátozott felhasználói fiókok Inicializáló file-ok Rendszerszintű inicializáló file-ok login.defs file Jelszavak Jelszavak és felhasználói fiókok Jelszó öregedés, elavulás Jelszavak kitalálása PAM rendszer Konfiguráció Kontroll paraméterek Modul visszatérési érték Példák Az other konfigurációs file PAM modulok pam unix.so Azonosítás USB eszközzel Összegzés Name Service Switch 43 7 FTP 45 8 MySQL adatbázis Bevezetés MySQL architektúrája Alapfogalmak Zárolás, locking Tranzakciók Adatbázis típusok Tároló motor választás Manuális installálás Installálás csomagból Beállítások Adatbázisok kezelése

5 8.9 Biztonsági kérdések Kezdeti konfigurálás Új felhasználó hozzáadása egyszerűen Hozzáférés kontroll Felhasználó által szolgáltatott adatok Hálózati védelem root jelszó helyreállítása Néhány biztonsági kérdés összefoglalása Adatbázis mentés és visszaállítás mysqldump program Loggolás Replikáció Kluszterezés Adatbázis optimalizálás Apache web szerver Bevezetés és alapok Mit csinál a web szerver? Mit csinál a web kliens? Miért az Apache? Az Apache web szerver Installálás Egyszerűsített installálás forrásból Manuális installálás forrásból Modulok kiválasztása Egyéb beállítások Fordítási folyamat Apache működtetésének alapjai Apache futtatása Apache leállítása A szervert futtató felhasználó Apache beállításai, konfigurációk Alap beállítások Blokk direktívák További opciók Virtuális host-ok Név alapú virtuális host-ok IP cím alapú virtuális host-ok Név és IP cím alapú virtuális host-ok Port alapú virtuális host-ok DNS szolgáltatás Domain nevek DNS adminisztráció alapjai

6 10.3 Név feloldás NFS és NIS szolgáltatások NFS alapok NIS alapok Problémák az NFS-es és NIS-el LDAP Címtár szerkezete Sémák Szerver telepítés és beállítás LDAP szerver beállítása Címtár feltöltése Hozzáadó parancsok Felhasználók a címtárban Egyéb parancsok LDAP egyszerű használata Keresés a címtárban Felhasználó azonosítás LDAP alapján LDAP kipróbálása PAM beállítása LDAP használatára Debian specialitás Biztonságosabb LDAP azonosítás phpldapadmin A Felhasznált irodalom 99 Tárgymutató

7 1. Fejezet Bevezetés Ez a könyv egy oktatási jegyzet és a benne foglaltak több forrásból származnak. Igyekeztem minden olyan információt összeszedni, amire egy rendszer adminisztrátornak szüksége lehet egy Linux rendszer esetén. A jegyzet főleg Debian alapú Linux rendszerekkel foglalkozik. Remélem mindenki hasznosnak fogja találni. Iványi Péter 7

8 8

9 2. Fejezet Kezdeti beállítások 2.1 Gép neve 2.2 Root 2.3 Hálózati beállítások DHCP konfigurálás A DHCP jelentése: Dynamic Host Control Protocol. A DHCP használatához a kliens gépeken a dhcp3-common és dhcp3-client csomagot kell felinstallálni. A DHCP szerveren a dhcp3-server csomagot is fel kell installálni. Szerver konfigurálás A szerver gépnek egy statikus, fix IP címmel kell rendelkeznie és ez legyen működő képes állapotban. Például az /etc/network/interface file tartalma lehet: auto eth0 iface eth0 inet static address netmask network broadcast Két fontos file-ban kell a beállításokat elvégezni. Először is meg kell adni, hogy melyik interfacen fog hallgatózni a DHCP szerver. Ezt az /etc/default/dhcp3-server file-ban lehet megtenni, például: INTERFACES="eth0" Itt természetesen több interface-t is megadhatunk SPACE-el elválasztva, például: "eth0 eth1". Ez a file lényegében egy rendszerváltozót definiál, amit majd az /etc/init.d/dhcp3-server indító script használ. Az indító script-ből nézzük meg azt a részletet, amelyik használja ezt a változót: start-stop-daemon --start --quite --pidfile $DHCPDPID \ --exec /usr/sbin/dhcpd3 -- -q $INTERFACES 9

10 A másik konfigurációs file az /etc/dhcp3/dhcpd.conf, amiben azt kell megadni, hogy milyen cím tartományt szolgáltasson a klienseknek. Ebben a file-ban például megadhatjuk a következőt: subnet netmask { range } Kliens konfigurálás A DHCP-t használó kliens gépeken az /etc/network/interface file tartalma a következő kell legyen: auto eth0 iface eth0 inet dhcp Ha el akarjuk dobni a szervertől kapott IP címet, akkor a következő utasítást kell használni: $ dhclient -r Internet Systems Consortium DHCP Client Copyright Internet Systems Consortium. All rights reserved. For info, please visit Listening on LPF/eth0/00:00:25:55:bb:b5 Sending on LPF/eth0/00:00:25:55:bb:b5 Sending on Socket/fallback DHCPRELEASE on eth0 to port 67 Új IP cím kérésekor a következő utasítás használható: $ dhclient -n 10

11 3. Fejezet Indítás és leállítás 3.1 Boot manager A Linux elindításához szükség van egy bootloader-re. A bootloader ismerete szinte elengedhetetlen, főleg akkor ha több operációs rendszert szeretnénk használni a számítógépünkön. Többféle bootloader is léterzik, de ezekből a két legelterjedtebb a LILO és GRUB. Ha Linux-ot Macintosh gépen akarunk futtatni, akkor pedig a yaboot bootloadert lehet csak használni MBR Az MBR (Master Boot Record) 512 byte hosszú rész a merev lemez legelején (a legelső szektorban). Az MBR két részből áll, egy 446 byte tartalmazza a boot code -ot és a maradék 66 byte tartalmazza a partíciós táblát (egy 2 byte-os szignatúrával együtt). A lilo és grub-install parancsok 1 az első 446 byte-ba írnak, a particionáló programoka pedig a 66 byte-os területre. FIGYELEM: Amikor az MBR területére írunk legyünk rendkívül óvatosak. Egy hibás byte és a teljes partíciót vagy merev lemezt is tönkretehetjük. Ha az MBR-t módosítjuk, érdemes elmenteni a teljes merev lemez állapotát! Az MBR elmentésére a következő parancsot lehet használni root-ként: # dd if=/dev/hda of=/root/hda.mbr bs=512 count=1 Az 512 byte-ot a hda.mbr nevű file mentjük el. Ha törölni akarjuk az MBR területét akkor a következő parancsot használhatjuk: # dd if=/dev/zero of=/dev/hda bs=512 count=1 Mind a két esetben az első merev lemezen található az MBR. A /dev/zero eszköz pedig arra való, hogy csupa nullát bocsásson ki magából és ezzel írjuk felül a területet. Amikor felülírjuk az MBRt akkor a lemezen található adatok többé nem érhetők el, így a partíciók, az adatok és az operációs rendszerek sem, de azért ne felejtsük el, hogy maga az adat a lemezen maradt. Így ha tényleg mindent törölni akarunk, akkor az adatokat is felül kell írni GRUB A két bootloader közül (LILO 2 és GRUB 3 ) kétségtelenül a GRUB bootloader a nagyobb tudású. (A legtöbb Linux disztribúció GRUB bootloader-el jelenik meg.) Például lehetőségünk van új kernelt vagy 1 DOS alatt a fdisk /mbr paranccsal lehet az MBR-t felülírni. 2 LInux LOader 3 GRand Unified Bootloader 11

12 paramétert megadni anélkül, hogy az MBR minden alkalommal frissíteni kellene. Bár a GRUB flexibilis és nagy tudású bootloader, de azért érdemes a boot szektort elmenteni, hogy katasztrófa esetén később vissza lehessen állítani. Ezt láttuk a fejezetben. A GRUB bootloader beállításait, konfigurálását, egy központi file-on keresztül lehet megtenni. Debian rendszeren a konfigurációs file a /boot/grub/menu.lst míg egy Red Hat rendszeren: /etc/grub/grub.conf A file több bejegyzést is tartalmaz, amelyek megadják a kernel nevét, a root partíciót, hol van a kernel és ha van akkor az initrd paramétereit is. Egy tipikus bejegyzés a file-ben a következő lehet: title Ubuntu, kernel root (hd0,2) kernel /vmlinuz root=/dev/hda3 ro quiet splash initrd /initrd.img Fontos tudni, hogy a GRUB a merevlemez partícióival dolgozik és egy kicsit másképpen hivatkozik rájuk mint a Linux. Linux alatt az első merev lemezre a /dev/hda-val lehet hivatkozni. Linux alatt betű jelöli a lemezeket: a, b, c és így tovább. Ha konkrét partícióra akarunk hivatkozni, akkor pedig még egy számot is használunk, például: /dev/hda3. Ezzel szemben GRUB alatt a merev lemezeknek számuk van, nullától indulva: 0, 1, 2 és így tovább. A partíciók száma is nullától kezdődik ezért ha a Linux partíciót a GRUB számára akarjuk megadni, akkor a betűt számmal kell helyettesíteni és a partíció számából egyet ki kell vonni. Például: a Linux partíció /dev/hda3 hd0,2 lesz GRUB alatt. A fenti példában ezért van kétféle megadási mód. A root kezdetű sor a GRUB-nak szól, míg a kernel kezdetű sorban a root paraméter már a Linux kernelnek szól. Ha egy másik operációs rendszer is van a számítógépünkön akkor azt is hozzá kell adni a konfigurációs file-hoz, hogy el lehessen indítani. Például Windows esetén egy lehetséges beállítás a következő lesz: title Windows 95/98/NT/2000 root (hd0,0) makeactive chainloader +1 Amikor nem Linux jellegű operációs rendszert kell betölteni, akkor általában használni kell a makeactive opciót amivel az operációs rendszerhez tartozó opciót aktívvá tesszük. A chainloader opcióval azt tesszük lehetővé, hogy a bootloader egy másik bootloader-t indítson el, például a Windows bootloaderét. Ha a számítógép indulásakor nem jelenik meg a bootloader menüje, az azért van mert a hiddenmenu opció szerepel a konfigurációs file-ban. Kommentezzük ki, ha szeretnénk a menüt látni. A menüben az alapesetként kijelölt operációs rendszert a default opcióval adhatjuk meg. A konfigurációs fileban szereplő operációs rendszer definíciókat a GRUB automatikusan beszámozza úgy, hogy az elsőhöz a nullás szám van hozzárendelve. Így, ha az első operációs rendszert akarjuk alapesetnek választani akkor a default 0 sort kell beírni a konfigurációs file-ba. A timeout opció pedig azt adja meg, hogy hány másodperc után automatikusan boot-oljon a kiválasztott operációs rendszer. 12

13 Grafikus kép boot-olás során A GRUB bootloader elég egyszerűen néz ki. Ugyanakkor lehetőségünk van egy háttérkép használatára, ami a menü mögött jelenik meg. A képnek teljesíteni kell három feltételt: XPM formátumúnak kell lennie, 640x480 pixel méretű kell legyen és nem tartalmazhat 14 színnél többet. Az XPM képet össze kell tömöríteni: # gzip hatterkep.xpm majd be kell másolni a boot könyvtárba: # cp hatterkep.xpm.gz /boot/grub Végül a GRUB konfigurációs file-jába a következő sort kell beírni: splashimage=(hd0,0)/boot/grub/hatterkep.xpm.gz feltételezve, hogy a boot partíció a /dev/hda1-nak felel meg LILO A LILO bootloader konfigurációs file-ja általában a /etc/lilo.conf. Az alább bemutatott minta file esetén feltételezzük, hogy egy Windows rendszer található az első partíción és a Linux a második partíción van: boot=/dev/hda map=/boot/map install=/boot/boot.b compact prompt timeout=50 image=/boot/vmlinuz label=linux root=/dev/hda2 read-only other=/dev/hda1 label=win boot=/dev/hda : A LILO bootloader az első merev lemez master boot rekordjába lesz installálva map=/boot/map : A map file-t a LILO generálja. Ne nyúljunk hozzá! install=/boot/boot.b : Ez a sor mondja meg, hogy a LILO mit használjon új boot szektorként. Ez a file tartalmazza azt a kódot, ami majd betölti az operációs rendszert. compact : Az opció megadásával a LILO gyorsabban fogja olvasni a merev lemezt. Néhány régebbi rendszer esetén nem működik. Ha a rendszer nem tud bebootolni, töröljük ezt a sort. prompt : Megadja, hogy egy menü jelenjen meg, amiből operációs rendszert választhatunk illetve paramétert adhatunk meg. 13

14 timeout=50 : Ez az opció adja meg, hogy hány másodpercig várjon a LILO, ami után a bootloader az alap operációs rendszert tölti be. image : A kernel file nevét adja meg. Maximum 16 féle kernel adható meg. Az első image szokott az alap beállítás lenni, hacsak más opciót nem adunk meg. Az utána következő sorok a kernel paraméterei lesznek betöltéskor. label : Ez az opció adja meg, hogy mi jelenjen meg a menüben, illetve a bootloader parancssorában is ezt a nevet adhatjuk meg a kernel bootolásához. root=/dev/hda2 : Megadja, hogy hol található a root partíció. read-only : Az opció hatására a bootloader csak olvasható állapotban tölti be a root file rendszert. Később a bootolás során újra betöltődik a root file rendszer. (Nem szabad megváltoztatni, hacsak nem tudod, hogy mit csinálsz!) other=/dev/hda1 : Ez opció olyan mint az image opció, csak ez azt adja meg, hogy nem Linux rendszert fogunk betölteni. A LILO egyszerűen az adott merev lemez boot rekordját fogja végrehajtani. Bármikor változtatást végzünk a lilo.conf file-ban, utáne le kell futtatni egy frissítést: # /sbin/lilo Grafikus kép boot-olás során LILO bootloader is képes a grafikus kép megjelenítésére a boot menü alatt. A grafikus kép megjelenítéséhez a grafikus kártyának támogatnia kell azt a VESA módot, melyben 640x480 méretű 255 szinű képet tud megjeleníteni. (A kernelnek nem kell támogatnia frame buffer módot, mivel amikor a LILO megjeleníti ezt a képet, akkor még a kernel nincs betöltve így a LILO nem támaszkodhat a kernelre.) A képben egy 255 elemű színpalettával kell megadni a színeket. (Angolul, a képnek Indexed -nek kell lennie.) A LILO bootloader konfigurációs file-jába (lilo.conf) a következő sorokat beírva bekapcsoljuk a grafikus képek megjelenítését illetve konfiguráljuk a megjelenést: install=bmp bitmap=/boot/lilo-boot-tux.bmp bmp-table=48p,15p,1,12 bmp-colors=250,,,255,, bmp-timer=300p,184p,250,, A bitmap kezdetű sorban lehet megadni, hogy a kép hol található. A bmp-table opció adja meg, hogy a képernyőn hova kerül a boot menü. Az opció formátuma: bmp-table=<x>,<y>,<oszlopok>,<sorok> ahol az x és y koordináták a menü bal felső pontjának a pixel koordinátáit adja meg. A szám utáni p betűvel jelöljük, hogy pixel koordinátákról van szó. Az opcióban megadható, hogy hány oszlop és hány sorból áll a menü. Például egy hat soros menü esetén: bmp-table=55,224,1,6 A bmp-timer opció adja meg, hogy a képernyőn hova kerül a stopper (időzítő) ami a visszaszámlálást végzi. Az opció formátuma: bmp-timer=<x>,<y>,<el}o-szín>,<háttér-szín>,<árnyék-szín> 14

15 Itt is a bal felső pont koordinátáit kell megadni. Az időzítő színei a képből határozhatók meg. A grafikus kép színpalettája 255 színt tartalmazhat. Az opció utolsó három értékét úgy lehet meghatározni, hogy az általunk választott szín indexét kikeressük a palettából és azt írjuk be a sorba. Például ha a kép színpalettájában a 0 indexű elem a fehér és a 254 indexű elem a fekete, illetve nem akarunk árnyék színt megadni, akkor a következő sort adhatjuk meg: bmp-timer=582p,455p,0,254, A bmp-colors opció a menü színeit adja meg. Az opció formátuma: bmp-colors=<el}o-szín>,<háttér-szín>,<árnyék-szín>,<sel-fg>,<sel-bg>,<sel-sh> ahol <sel-fg> a kiválasztott sor előtér-színe, a <sel-bg> a kiválasztott sor háttér-színe és a <sel-sh> a kiválasztott sor árnyék színe. A színek indexei itt is a kép színpalettájából származnak. Végül a boot rekord frissítésére futtassuk le a következő parancsot: # /sbin/lilo Bootloader megkerülése Előfordulhat, hogy az MBR-t tönkretettük, vagy valamiért megsérült és mégis szeretnénk bebootol-ni egy operációs rendszert. Az is előfordulhat, hogy egy új kernelt akartunk használni, de nem működik és a régi kernelt szintén töröltük. Minden esetre szeretnénk használhatóvá a számítógépünket. A legtöbb installációs CD használható a számítógépen levő operációs rendszer megvizsgálására és helyreállítására. Az installációs CD végrehajtása során a számítógépünk érintetlen marad amíg el nem kezdjük particionálni a merev lemezt. Amikor aljutunk eddig a pontig, ne kezdjük el a particionálást, hanem próbáljuk ki a Ctrl-Alt-F(n) (például: Ctrl-Alt-F3) billentyű kombinációt. A billentyűk lenyomásával egy virtuális terminálra jutunk. (Lehet hogy néhányszor meg kell nyomni az Enter billentyűt, hogy aktiválódjon. Az installációs CD-ken a virtuális terminálokban egy kis méretű shell áll rendelkezésre, BusyBox. A BusyBox shell egy szokványos shell csökkentett változatának felel meg, de minden szükséges parancsot tartalmaz. Miután a shell rendelkezésre áll, be kell mount-olni a merev lemez azon partícióját, ahol például a /boot könyvtár van. Például: # mkdir /bootmnt # mount /dev/hda1 /bootmnt Ha egyéb módosításra is szükség van, akkor a root partíciót is be kell mount-olni: # mkdir /rootmnt # mount /dev/hda3 /rootmnt A merev lemezen található root partíció betöltése után ezt kell aktuálissá tenni, hogy a merev lemezen levő parancsok elérhetők legyenek: # chroot /rootmnt Egyéb bootloader-ek 15

16 3.2 Bootolás initrd Tegyük fel, hogy olyan számítógépünk van amiben SCSI vezérlésű merev lemez van. Általában ezek a merev lemezek speciális meghajtót igényelnek. A bootloader a BIOS megszakításokon keresztül hozzáfér a merev lemezhez és be tudja tölteni a kernelt (rendszermagot). Ugyanakkor előfordulhat, hogy a a kernelhez modulok tartoznak, vagyis bizonyos szolgáltatások csak külső, de betölthető modulként állnak rendelkezésre. Például az SCSI vezérlő programja modulként is fordítható a kernelhez. Ez egy csapda helyzethez vezethet. A bootolás során a kernel már a memóriában van, de nem tudja betölteni a root file rendszert mivel ahhoz az SCSI vezérlő modul kellene, ami viszont a root file rendszeren van. A probléma feloldására két megoldás is létezik: 1. Az első esetben a kernelbe van fordítva az SCSI támogatás és így a kernel hozzáfér az SCSI merev lemezhez. 2. A második esetben initrd file rendszert használunk, ami egy előzete gyökér könyvtárnak felel meg. Az initrd az Initial RAM Disk rövidítése. Ez egy kis file rendszer, amit a bootloader tölt be és a kernel a velódi root file rendszer helyett tölt be. A kernel RAM lemezként tölti be a file rendszert, végrehajtja a /linuxrc file-t, majd felcsatolja a valódi root file rendszert Boot scriptek 3.3 Leállítás A rendszer leállításához a shutdown parancsot használjuk. A parancs figyelmeztet minden felhasználót, mindent processzust, hogy a rendszer leáll, blokkolja az új belépéseket és tisztán leállítja a rendszert. (Ha csak kihúzzuk az elektromos kábelt a falból a rendszer megfelelő leállítása nélkül az később problémákhoz és adatvesztéshez vezethet. A rendszer teljes leállításához a -h opciót használjuk, a rendszer újraindításához a -r opciót kell használni Azonnali leállítás A leállításnál azt is megadhatjuk, hogy mikor történjen meg. Például, ha azonnal szeretnénk leállítani a rendszert, akkor a now argumentumot is meg kell adni. Például, az azonnali leállításhoz: # shutdown -h now parancsot kell megadni, míg az azonnali újraindítéshoza a következőt kell begépelni: # shutdown -r now A shutdown parancs azt is lehetővé teszi, hogy figyelmeztető üzenet jelenjen meg minden terminálon, ahol felhasználó be van jelentkezve: # shutdown -h now A gep azonnal leall! Leállítás adott időben Adott időben történő leállításhoz az időt 24 órás formátumban kell megadni. Például ha reggel 4:23-kor akarjuk leállítani a gépet a következőt kell begépelni: 16

17 # shutdown -h 4:23 míg az este 8 órás leállításhoz # shutdown -h 20:00 a fenti parancsot kell begépelni. A rendszer x perc múlva történő leállításához egy plusz jelet ( + ) és a percet kell megadni a parancs után. Például ha a rendszert leállítjuk 5 perc múlva a következőt gepelhetjük be: # shutdown -h +5 Természetesen az üzenet küldési argumentum ezeknél a prancsoknál is használható: # shutdown -h 00:00 A gep leall ejfelkor karbantartas miatt! A leállítás visszavonása Előfodulhat, hogy egy időzített leállítást mégsem szeretnénk végrehajtani, vagyis szeretnénk visszavonni. Ehhez a shutdown parancsot ismételten le kell futtatni: # shutdown -c Ez minden már elindított leállítási folyamatot visszavon, leállít. Ebben az esetben is lehet üzenetet küldeni a felhasználóknak: # shutdown -c Bocsanat, rossz gombot nyomtam le! 17

18 18

19 4. Fejezet Felhasználók és csoportok A felhasználók vagy felhasználói fiókok (user account) és csoportok (group) kezelése, illetve a felhasználók azonosítása talán a legfontosabb feladat, amit a rendszergazdának el kell látnia. A felhasználói fiókokra azért van szükség, mivel ezeken keresztül férünk hozzá a rendszerhez, ezekkel bizonyítjuk hogy kik vagyunk és hogy jogunk van-e hozzáférni az információkhoz és az erőforrásokhoz a számítógépen. Így ez a fejezet több lépésben és több szempontból foglalkozik a felhasználói fiókokkal. 4.1 Alapok A Unix és így a Linux is többfelhasználós operációs rendszer, vagyis egy időben több felhasználó is dolgozhat a rendszeren. Az operációs rendszer szempontjából a felhasználó nem feltétlenül egyetlen ember. A felhasználó tulajdonképpen egy olyan entitás akinek/aminek joga van programokat futtatni a rendszeren, vagy file-okat birtokol a rendszeren. Például vannak olyan felhasználói fiókok, melyek csak azért léteznek, hogy egy szolgáltatáshoz tartozó programot lefuttassanak. Ezeket a felhasználói fiókokat pszeudo felhasználóknak nevezzük. Természetesen a legtöbb esetben a felhasználói fiók egy személyhez köthetők. Minden felhasználónak van egy felhasználói neve (username) ami a rendszeren azonosítja. Mint látni fogjuk, ennél fontosabb, hogy minden felhasználóhoz tartozik egy felhasználói azonosító szám: user identification number or UID. Valójában az operációs rendszerben ez a szám azonosítja a felhasználót és a felhasználói név csak hozzá van rendelve. Ezen kívül minden felhasználó egy vagy több csoportba is tartozik. Egy csoportba olyan felhasználók tartoznak, akik azonos feladatot végeznek, esetleg azonos szervezetben dolgoznak vagy valami egyéb közös tulajdonságuk van. Ebben az esetben is egy csoport azonosító szám (group identification number, GID) jellemzi a csoportot az operációs rendszerben belsőleg, amihez a csoport neve csak hozzá van rendelve. Az UID és GID számok közösen határozzák meg, hogy milyen jogaink vannak a rendszeren, milyen file-okhoz férünk hozzá. A Unix rendszereken a file-ok és könyvtárak biztonsága olyan stratégiával valósul meg ami közvetlenül köthető a felhasználói azonosítókhoz és csoport azonosítókhoz! A felhasználói fiókok és a csoportok adatait a következő file-ok tárolják: /etc/passwd : felhasználói fiókok definíciója /etc/shadow : kódolt jelszavak és tulajdonságaik /etc/group : csoportok definíciója és csoport tagok /etc/gshadow : csoport jelszavak (csak Linux-on) 19

20 4.2 /etc/passwd file Az /etc/passwd file minden felhasználóról tartalmaz egy bejegyzést 1. Egy bejegyzés egy sorból áll, melynek általános szerkezete a következő: username:x:uid:gid:gecos:home-dir:login-shell A bejegyzésben a mezőket a kettőspont választja el és a SPACE karakter csak a gecos mezőben megengedett! A kis és nagy betűk különbsége fontos ebben a file-ban! A mezők egyes jelentése: username : Ez a mező adja meg a szöveges felhasználói nevet. Általában 8 karakterben limitált, de bizonyos Unix rendszerek hosszabb nevet is megengednek. Ez az információ mindig nyilvános, mivel több program is használja. x : Hagyományosan a második mező a kódolt jelszót tartalmazta, de a shadow jelszavak bevezetése óta ez a mező már csak az x karaktert tartalmazza. Bővebb magyarázat a 4.3. bekezdésben. UID : A user identification number vagy felhasználói azonosító szám. Minden felhasználónak egyedi száma van. A rendszer felhasználók ( system account ) azonosító száma általában 100 alatti. (Linuxon manapság 500 alatti és FreeBSD rendszeren az 1000 alatti azonosító számok tartozhatnak a rendszer felhasználókhoz.) Bizonyos rendszeradminisztrátorok valamilyen sémát alkalmaznák az azonosítók felhasználókhoz történő hozzárendelése során. Például: Informatika tanszék: , Építőmérnöki tanszék: és így tovább. Fontos, hogy ha két felhasználónak ugyanaz az azonosító száma, akkor a rendszer szempontjából egy felhasználónak számítanak! Kerüljük ezt a típusú problémákat. GID : A felhasználó elsődleges csoportjának az azonosító száma. A csoport azonosító számnak megfelelő csoportnevet a /etc/group file-ban találhatjuk meg. Az azonos csoportba tartozó felhasználók megoszthatnak file-okat egymás között ha a file csoport jogosultsága megfelelően van beállítva. Általában itt is igaz, hogy a 100 alatti számok rendszer felhasználókhoz tartoznak. gecos : Ez a mező bármilyen információt tartalmazhat a felhasználóról, pl. a felhasználó teljes nevét, irodájának számát, stb. home-dir : A felhasználó home könyvtára, vagyis a belépés után a felhasználó ebbe a könyvtárba kerül, illetve ebben a könyvtárban tárolhatja a felhasználó a saját file-jait. login-shell : A belépés után az operációs rendszer egy parancs értelmezőt, vagy angol nevén shell -t indít el. Ez a bejegyzés adja meg, hogy melyik parancs értelmező induljon el, mivel többféle is létezik: Bourne shell : /bin/sh C shell : /bin/csh Korn shell : /bin/ksh Bash shell : Lényegében egy Bourne shell, de több hasznos kiegészítést tartalmaz. A Linux rendszereken szinte kizárólag ezt a shell-t használják. A legtöbb rendszeren az /etc/shells file tartalmazza a shell-ek listáját. Egy tipikus bejegyzés az /etc/passwd file-ban a következő lehet: kovacs:x:222:120:kovacs Istvan:/home/kovacs:/bin/sh 1 Ezt a kijelentést később még módosítjuk 20

21 4.2.1 Az /etc/passwd file módosítása Mivel az /etc/passwd file egy egyszerű ASCII file, ezért bármilyen szövegszerkesztővel módosítható. Figyelem: Amikor az /etc/passwd file-t módosítjuk legyünk óvatosak! Például először készítsünk biztonsági másolatot a file-ról. $ cd /etc $ cp passwd passwd.bak $ vi passwd Ennél biztonságosabb módszer, ha nem közvetleznül a /etc/passwd file-t módosítjuk, hanem a másolatot majd miután végeztünk visszamásoljuk a /etc/passwd file helyére: $ cd /etc $ cp passwd passwd.new $ vi passwd.new... $ cp passwd.new passwd Végül a legbiztonságosabb módszer a vipw program használata. A program készít egy másolatot az adott file-ről, majd egy szövegszerkesztő programot elindítva lehetővé teszi a file biztonságos módosítását. A másolat file egy zároló mechanizmusként is szolgál, mivel a vipw program nem indul el akkor ha a másolat file létezik. Ezzel a módszerrel kizárhatjuk, hogy egyszerre ketten szerkesszék ugyanazt a file-t. A vipw program azt a szövegszersztőt választja, ami az EDITOR környezeti változóban van megadva. (Ha sem a VISUAL és sem a EDITOR környezeti változó nincs megadva, akkor a vi szövegszertő indul el.) Mielőtt a vipw program elmentené a file-t, néhány ellenőrzést végez, majd ha nincs semmi probléma, akkor az eredeti file-t átnevezi (Linuxon az új file neve általában /etc/passwd-) és végül kiírja a módosított adatokat az eredeti file-ba. A vipw programnak megfelelően van egy vigr program is, ami pedig az /etc/group file-t szerkeszti. Mindkét programnak meg lehet adni a -s opciót ami lehetőve teszi a shadow file-ok szerkesztését. A vipw -s program az /etc/shadow file-t, a vigr -s program az /etc/gshadow file-t tudja szerkeszteni. 4.3 /etc/shadow file A legtöbb Unix rendszer támogatja a shadow jelszó tárolási módszert. Miért kell ez? A Unix rendszereken az /etc/passwd file mindenki által olvasható file-nak kell lennie, mivel bármilyen programnak vagy szolgáltatásnak szüksége lehet arra, hogy a felhasználói névből UID számot kapjunk és fordítva (UID számból felhasználói nevet). Ugyanakkor a mindenki által olvasható file problémát jelent, mivel mindenki, még a rossz fiúk is másolatot készíthetnek róla. Ez azt jelenti, hogy ha a jelszavak a file-ban vannak, akkor azok is olvashatók mindenki által. Gondolhatnánk, hogy akkor elég lenne a kódolt jelszavakat tárolni a file-ben és ez megoldja a problémát. A helyzet az, hogy így egy kicsit biztonságosabbnak látszik a rendszer, de valójában nem az. A rossz fiúk jelszó törő (crack) programot használhatnak. A crack program a jelszó nagyon sok variációját végigpróbálja, mindegyik jelszót kódolja és megnézi, hogy a kódolás eredménye ugyanaz-e mint ami a jelszó file-ban van. Ezzel a módszerrel a 80-as években sok jelszót sikerült feltőrni és a módszer angol neve brute force vagyis nyers erő módszer. (A módszer nem csak jelszavak megtalálásánál működik, hanem minden olyan esetben amikor az összes variációt végig tudjuk próbálni.) A shadow file lényege, hogy az /etc/passwd file csak a szükséges adatokat tartalmazza, de a jelszó átkerül a shadow file-ba. A shadow file-t csak a root felhasználó olvashatja és írhatja, így a kódolt jelszó védve van az előbb leírt támadási módszerrel szemben. A shadow file általános helye: /etc/shadow, és a file formátuma abban hasonló az /etc/passwd file-hoz, hogy minden felhasználóhoz egy sor tartozik, aminek a következő a szintakszisa: 21

22 username:jelszó:utolsó-vált:minlife:maxlife:warn:inactive:lejár:nem-használt A username adja meg a felhasználói nevet (aminek a párja az /etc/passwd file-ban van) és a jelszó mező tartalmazza a kódolt jelszót. A többi mező a jelszó öregedési metódus paraméterei és a bekezdésben tárgyaljuk. 4.4 /etc/group file A felhasználói csoportokat lehet megadni az /etc/group file-ban. Az egy csoportba tartozó felhasználók file-okat és rendszer erőforrásokat tudnak megosztani. Kétféle módon lehet megadni, hogy felhasználó melyik csoportba tartozik: 1. az /etc/passwd file negyedik mezője GID-el adja meg, 2. az /etc/group file-ban adjuk meg explicit módon. A legtöbb Unix rendszeren egy felhasználó csak 16 csoportba tartozhat! 2 Az /etc/group file minden sora külön bejegyzésnek számít, aminek a formátuma: név:*:gid:felhasználói-nevek-listája ahol az egyes mezők jelentése: név : Ez a mező adja meg a csoport nevét. * : Hagyományosan a második mező tartalmazta a csoport jelszót, de ma már csak egy helyettesítő karaktert tartalmaz, mivel a csoport jelszavak a /etc/gshadow file-ban találhatók. (Igazából, ma már csak Linux használja a csoport jelszavakat.) GID : A csoport azonosító szám. Itt is általában igaz, hogy a 100 alatti értékek a rendszer csoportokhoz tartoznak. felhasználói-nevek-listája : Ez a bejegyzés a csoportba tartozó felhasználók listáját tartalmazza, ahol is a nevek vesszővel vannak elválasztva. A csoportba nem csak azok a felhasználók tartoznak, akik itt fel vannak sorolva, hanem azok a felhasználók is akiknek a GID bejegyzése a /etc/passwd file-ban ennek a csoportnak az azonosítójával egyenlő. A felsorolt felhasználói nevek megfelelnek az /etc/passwd file-ban található neveknek. Egy tipikus bejegyzés az /etc/group file-ban a következő lehet: gazdasag:*:123:kiss,nemeth,kovacs oktatas:*:222:nagy,jozsa,kovacs it:*:120: Fontos megérteni, hogy ha a felhasználói név és a csoport ugyanaz is, és esetleg az UID és a GID is azonos, attól még két teljesen különböző dologról van szó és nincs semmi kapcsolat közöttük! Az /etc/group file közvetlenül is módosítható, de a vigr program is használható a biztonság kedvéért. 2 Vannak olyan Unix rendszerek, amelyeken minden felhasználó egy olyan csoportba tartozik, melynek csak az az egy felhasználó a tagja: user private group vagy UPG. Ilyen rendszer a Red Hat Linux és a Debian is ezt a stratégiát alkalmazza alap esetben. 22

23 4.4.1 Elsődleges csoport A Unix rendszerek nem tesznek különbséget a két módszer között, ahogyan a felhasználókat csoportba soroljuk. A felhasználó egyszerre mindegyik csoportjába tartozik. Egy felhasználó csoportjainak kiíratására a groups parancs használható: $ groups gazdasag vezetes Egy adott felhasználó csoportjainak a kiíratására a parancsnak a felhasználói nevet is meg lehet adni: $ groups kovacs gazdasag oktatas it Mindezzel szemben van olyan eset, amikor fontos, hogy a felhasználónak mi az elsődleges csoportja. Például, amikor nyilvántartást végzünk, hogy melyik kutatócsoport milyen mértékben használja az adott számítógépet, akkor fontos, hogy a megfelelő csoport legyen az elsődleges csoport az adott felhasználónál. Az elsődleges csoport kiválasztására a newgrp parancs használható: $ newgrp kemia A parancs egy új shell-t nyit meg, amiben a felhasználó elsődleges csoportja a parancs argumentumaként megadott érték. Ha a parancsnak nem adunk meg argumentumot, akkor az /etc/passwd file-ban megadott, alapértéket állítja be a rendszer. Az elsődleges csoport azonosító lekérdezésére az id parancs alkalmas: $ id uid=222(kovacs) gid=120(it) groups=123(gazdasag),222(oktatas),120(it) A gid paraméter adja meg az elsődleges csoportot. 4.5 /etc/gshadow file A Linux rendszereken egy extra file járul a hagyományosan ismert /etc/passwd, /etc/shadow és /etc/group file-okhoz, mégpedig a /etc/gshadow file, ami a csoportok rejtett jelszavait tárolja. A file szintakszisa: csop-név:kódolt-jelszó:csop-admin:felhasználó-lista A csop-admin a csoportot felügyelő felhasználó, akinek joga van a jelszót megváltoztatni. A felhasználó-lista ugyanazokat a felhasználókat tartalmazza mint ami a csoport bejegyzés mellett van az /etc/group file-ban. Nézzünk néhány példát: oktatas:xxxxxxxx:jack:joe,jim,anna vezetes:*:root:root,jack Fontos látni a fenti példából, hogy attól hogy egy felhasználó a csoport admin-ja, még nem lesz a csoport tagja. Ezt külön meg kell adni, ahogy ez a második sorban látható. A második mezőben a csillag karakter ( * ) azt jelenti, hogy a csoport blokkolt, vagyis egyetlen felhasználó sem tudja az elsődleges csoportját erre a csoportra állítani. 23

24 4.6 Csoportok hozzáadása A csoportok lényege, hogy amikor a felhasználók bizonyos körének egy vagy több állomány vagy alkalmazás felett azonos jogosultsággal kell rendelkeznie akkor ne kelljen a jogosultságokat minden felhasználóra külön-külön beállítani, hanem egyszerre végezhessük el a jogosultság kezelést a csoportba tartozó minden felhasználóra. Egy csoport létrehozása igen egyszerű, mert tulajdonképpen csak egy sor bejegyzést kell írni az /etc/group file-ba, a fent tárgyalt szintakszis alapján. Ennél jobb megoldás a vigr program használata, de létezik külön parancs a csoportok létrehozására: groupadd. Példa egy csoport létrehozására: $ groupadd tanarok A parancs a sorban következő, nem rendszergazdai csoport azonosító számot (GID) fogja hozzárendelni a tanarok csoporthoz. Ha explicit módon szeretnénk megadni a csoport azonosító számot, akkog a -g kapcsolót kell használni: $ groupadd -g 1256 tanarok A program figyel arra, hogy egyedi nevet és GID-et adjunk meg a csoportok esetén. Ha valamelyik adat mégsem egyedi akkor a program hibával fog kilépni. A -o kapcsoló segítségével megengedhetjük a nem egyedi GID használatát. A rendszer csoportok létrehozásához a -r kapcsolót kell megadni, illetve csoport jelszó esetén a -p kapcsolóval a kódolt jelszót. Például: $ groupadd -r -p 2Isrg5623Gre tanarok A parancs működését befolyásolja a /etc/login.defs konfigurációs file-ben megadott néhány paraméter, például: GID_MAX, GID_MIN : Ezek az értékek adják meg, hogy a nem rendszer szintű csoportok GID-je milyen tartományba essen. SYS_GID_MAX, SYS_GID_MIN : Ezek az értékek adják meg, hogy a rendszer szintű csoportok GID-je milyen tartományba essen. Általában szokott lenni a két érték. 4.7 Csoportok módosítása A csoportok módosítására a groupmod parancs alkalmas. Meg lehet változtatni a csoport nevét: $ groupadd -n oktatok tanarok ahol a tanarok helyett oktatok lesz a csoport neve. A csoport azonosító szám (GID) is megváltoztatható, de ebben az esetben manuálisan kell azokat a file-okat megváltoztatni, amelyeknek a csoport tulajdonosa a régi csoport volt. Ha ezt nem tesszük meg, a csoport tulajdonos esetén csak egy számot (a régi számot) fogja a rendszer kinyomtatni. Példát lásd a következő bekezdésben. 4.8 Csoportok törlése A csoportok törlésére a groupdel parancs alkalmas. Például: $ groupdel nyugdijasok A csoportnak léteznie kell. A parancs csak a bejegyzéseket törli a file-okból, de a rendszeren található file-ok csoport tulajdonjogát nem változtatja meg. 24

25 $ groupadd testcsop $ touch file $ chgrp testcsop file $ ls -l file -rw-r--r-- 1 user testcsop :00 file $ groupdel testcsop $ ls -l file -rw-r--r-- 1 user :00 file A fenti példában az látható, hogy a csoport törlése után a file csoport tulajdonosa nem változott meg, csak a rendszer most már nem tudja feloldani, nem találja a 61-es GID-et a /etc/group file-ban. 4.9 Felhasználók létrehozása A legtöbb Linux rendszeren kétféle parancs is rendelkezésre áll a felhasználók létrehozására: adduser és useradd. A useradd az alacsonyabb szintű parancs így igazából az adduser parancs használatát szokták javasolni useradd parancs A parancs legegyszerűbb formája: $ useradd kovacs aminek a hatására a parancs létrehozza az alapértékek alapján. Az alapértékek az /etc/default/useradd file-ban találhatók. A file lehetséges tartalma: GROUP=100 HOME=/home SKEL=/etc/skel SHELL=/bin/sh INACTIVE=-1 EXPIRE= A GROUP kulcsszó a felhasználók elsődleges csoportját adja meg. Ugyanakkor több rendszer is azt a stratégiát használja, hogy minden felhasználót egy a felhasználói névvel megegyező külön csoportba rak. (Lásd user private group a 4.4. bekezdésben.) A useradd parancs alapesetben így működik, de ha ezt a viselkedést felülírjuk, akkor használja a parancs a GROUP értékét. A HOME kulcsszó adja meg, hogy melyik könyvtár alá kerüljenek a felhasználók könyvtárai. A SKEL opció adja meg annak a könyvtárnak a helyét ahol azok a file-ok és könyvtárak (!) találhatók amiket egy új felhasználó könyvtárába be kell másolni a felhasználói fiük léterhozása során. A SKEL kifejezés a skeleton vagyis váz angol szóból származik, ami azt jelöli, hogy ez a könyvtár adja meg a felhasználói könyvtárak vázát, mintáját. A SHELL opció határozza meg, mi lesz a felhasználó shell-je. Az INACTIVE határozza meg, hogy hány nap múlva jár le a jelszó, és így mikor kell lecserélni, illetve az EXPIRE adja meg, hogy mikor jár le a felhasználói fiók. A parancsnak számos kapcsolója ven, mellyel különböző beállításokat tehetünk: -c szoveg : Bármilyen szöveg ami a gecos mezőbe kerül az /etc/passwd file-ban. -u UID : Ha saját magunk szeretnénk megadni a fehasználói azonosító számot, akkor ezt az opciót kell használni. A szám nem lehet negatív és egyedinek kell lennie (kivéve ha a -o opciót is használjuk, ami nem ajánlott!!). 25

26 -g GID : A felhasználó elsődleges GID-je adható meg explicit módon. Ez a GID fog az /etc/passwd file-ba kerülni. A további csoportokat a -G csop1,csop2,... opcióval lehet megadni, amelyek csak az /etc/group file-ban jelennek meg. -m : A parancs alapesetben nem hozza létre a felhasználó könyvtárát. Ennek az opciónak a megadásával utasíthatjuk a parancsot, hogy hozza létre a könyvtárat. Példa a parancs használatára: $ groupadd -g 3333 vezetok $ groupadd -g 3334 oktatok $ groupadd -g 3335 gazdasag $ useradd -u g G 3334,3335 -m nagy Először a csoportokat hozzuk létre, majd az első csoporthoz adjuk hozza a 2222 UID számú és nagy nevű felhasználót, illetve a könyvtárát is létrehozzuk. A parancs hatására a felhasználó két további csoportba is bekerül. Ha egy másik felhasználó könyvtárát akarjuk mintaként használni egy új felhasználó könyvtárához a következő parancsot lehet kiadni: $ useradd -m -k /home/minta nagy ahol a minta felhasználó könyvtárában levő file-okat és könyvtárakat átmasolja a nagy felhasználó könyvtárába, ugyanakkor az átmásolt file-ok tulajdonosa már a nagy felhasználó lesz. Még egy trükköt érdemes itt megemlíteni. Tegyük fel, hogy egy felhasználónak meg akarjuk engedni, hogy FTP-vel (lásd 7. fejezet) file-okat tudjon felmásolni illetve tudjon letölteni, de ugyanakkor azt akarjuk, hogy soha ne tudjon bejelentkezni egy shell-be. Ebben az esetben a felhasználónak léteznie kell a rendszeren és érvényes jelszavának is kell lennie. Ahhoz hogy ne tudjon shell-be bejelentkezni egy speciális shell-t kell definiálni a létrehozása során: $ useradd -s /bin/false ftp-user A /bin/false program nagyon speciális, mivel nem csinált semmit, de olyan kóddal tér vissza ami azt jelzi, hogy sikertelen volt a futása és így a rendszer nem fog shell-t adni a felhasználónak. Az /etc/passwd file-ban a bejegyzés valahogy így nézne ki: ftp-user:x:1003:1003:csak ftp:/home/ftp:/bin/false Megjegyzések FONTOS: A parancs alap esetben zárolt felhasználókat hoz létre. A jelszó vagy explicit módon megadható már kódolt formában a -p opcióval, vagy a passwd user paranccsal. A létrehozandó felhasználó nem szereplhet NIS (lásd 11. fejezet) illetve LDAP (lásd 12. fejezet) adatbázisban sem. A felhasználó neve lehetőség szerint csak kis betűből, számokból, aláhúzás és minusz karakterekből álljon. A végén állhat egy dollár jel. A felhasználói neveket leíró reguláris kifejezés a következő lehetne: [a-z_][a-z0-9_-]*[$] 26

27 4.9.2 adduser parancs Ez a parancs, ha semmilyen paramétert nem adunk meg a felhasználóról, akkor a shell-ben kérdéseket tesz fel, amikre válaszolva adhatjuk meg a felhasználói fiók tulajdonságait, például: $ adduser proba5 Adding user proba5... Adding new group proba5 (1001)... Adding new user proba5 (1002) with group proba5... Creating home directory /home/proba5... Copying files from /etc/skel... Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully Enter the new value, or press ENTER for the default Full Name []: 1 Room Number []: 2 Work Phone []: 3 Home Phone []: 4 Other []: 5 Is the information correct [Y/n]: y $ Az /etc/passwd file-ban létrehozott bejegyzés a következő lesz: proba5:x:1002:1001:1,2,3,4,5:/home/proba5:/bin/bash amiből az látható, hogy a megadott paraméterek ugyanúgy a gecos mezőbe kerültek, csak vesszővel elválasztva. Nézzük meg, hogy a finger parancs mit írna ki ebben az esetben: $ finger proba5 Login: proba5 Name: 1 Directory: /home/proba5 Shell: /bin/bash Office: 2, 3 Home Phone: 4 Never logged in. No mail. No plan. Ez a példa azt mutatja, hogy a gecos mezőben eltárolt adatokat vesszővel érdemes elválasztani, ha azt akarjuk, hogy a megfelelő információ a megfelelő helyen jelenjen meg Amikor nincs segítség Ebben a bekezdésben azzal módszerrel ismerkedünk meg, amikor semmilyen extra parancs nem áll rendelkezésre a rendszeren és mindent kézzel kell végrehajtani. A felhasználó létrehozásának a következők a lépései: Az /etc/passwd file-ban a felhasználói név, UID, elsődleges csoport és nehány egyéb információ megadása. A jelszó megadása az /etc/shadow file számára. A home könyvtár létrehozása. A kezdeti file-ok átmásolása a home könyvtárba. 27

28 A chown paranccsal a tulajdonjogok beállítása a home könyvtárra és a benne levő file-okra. A felhasználó hozzáadása további alrendszerekhez, pl. quota. Adjunk jogosultságot egyéb alrendszerekhez, pl. FTP. Egyéb gép specifikus inicializálás A felhasználói fiók kipróbálása. $ vi /etc/passwd... user1:x:1005:1005:teszt user:/home/user1:/bin/sh... $ vi /etc/shadow... user1:!:14518:0:99999:7:::... $ passwd user1 Enter new Unix password: Retype new Unix password: $ vi /etc/group... user1:x:1005:... $ vi /etc/gshadow... user1:!::... $ cd /home $ mkdir user1 $ cp -r /etc/skel/* /home/user1 $ chown -R user1:user1 /home/user1 $ chmod -R 755 /home/user1 További beállítások végezhetők el az /etc/security/ könyvtárban található file-okban, például korlátozhatók 4.10 Felhasználók törlése Egy felhasználó törölhető a userdel vagy deluser parancsok egyikével. Itt is az egyik alacsonyabb szintű mint a másik változat. A felhasználó törölhető például a következő módon: $ deluser user1 Figyelem, alap esetben a parancsok nem távolítják el a home könyvtárat vagy például a csoportot. Ezt külön meg kell adni opciókkal: $ deluser --remove-home user Felhasználók módosítása Egy felhasználói fiók blokkolható a passwd paranccsal: 28

29 $ passwd -l user1 A blokkolás egyébként nagyon egyszerű, mivel csak annyi történik, hogy az /etc/shadow file-ban a második mezőbe belekerül egy csillag ( * ) vagy felkiálltó jel (! ) karakter. A felhasználói fiók újraaktiválásához elegendő a csillag vagy felkiálltó jel karaktert törölni az /etc/shadow file-ban a második mezőből vagy a passwd parancsot használni: $ passwd -u user Felhasználó és csoport adminisztráció Az ebben a fejezetben bemutatott file-ok esetén elengedhetetlen, hogy a jogosultságok megfelelően legyenek beállítva. Mindegyik file esetén a root legyen a tulajdonos és csak root tudja írni a fileokat. Például: -rw-r--r-- 1 root root 564 Oct 2 12:01 /etc/group -rw-r--r-- 1 root root 531 Oct 2 12:01 /etc/group- -rw-r--r-- 1 root root 985 Oct 2 12:01 /etc/passwd -rw-r--r-- 1 root root 894 Oct 2 12:01 /etc/passwd- -rw root shadow 1185 Oct 2 12:01 /etc/shadow -rw root shadow 1085 Oct 2 12:01 /etc/shadow- A fenti listában azok a file-ok amelyek végén egy minusz jel ( - ) van backup file-ok, amik az adott file utolsó előtti állapotát tárolja. Így ha valami hibát vétettünk, az előző állapot mindig visszaállítható. Fontos: A shadow file-ok csak a root által legyenek olvashatók és írhatók. Erről mindig győződjünk meg! Szabványos felhasználók és csoportok Minden Unix rendszeren vannak előre definiált felhasználók és csoportok. Ezekből a root-ot biztosan használjuk, a többi valószínűleg pszeudo felhasználók és jelszavakon keresztül blokkolt felhasználói fiókok. Gyakran előforduló előre definiált felhasználók: root : A szuperuser, a rendszeradminisztrátor. UID azonosítója 0. Itt a fontos, hogy az UID zérus, a felhasználói név bármi lehet. bin, daemon, adm, lp, sync, shutdown, sys : Ezek a rendszer felhasználói fiókok és különböző rendszer file-ok tulajdonosai lehetnek vagy rendszer processzusokat futtatnak. Az igazság az, hogy a Unix rendszerek definiálják ezeket a felhasználókat, de nem igazán használják. mail, news, ppp : Szintén rendszer felhasználói fiókok, amelyek a rendszer valamelyik alrendszeréhez kötődnek, pl. levelezés. mysql, xfs : Opcionális rendszer komponensekhez szükséges felhasználói fiókok, pl. adatbázis, X Window font szerver. nobody : AZ NFS alrendszer és néhány egyéb alrendszer által definiált felhasználói fiók. UID értéke általában a -2, de bizonyos rendszereken más is lehet, pl. System V rendszeren: Csoportok listája hasonló a fenti listához. A root csoport GID-je 0. Hasonlóan van bin, daemon, stb. az /etc/group file-ban. Ezeken kívűl a 100-as GID általában a users vagy staff csoporthoz tartozik. 29

30 Korlátozott felhasználói fiókok A bekezdésben a /etc/false shell használatával már láttunk egy módszert, amivel a felhasználót korlátozni lehet abban hogy mit csinálhat a rendszeren. Ugyanakkor előfordulhat az is, hogy többet akarunk engedni, de azért mindent mégsem, vagyis korlátozott shell -t (restricted shell) akarunk biztosítani. Például egy adminisztrátornak csak egy feladatot ellátnia és így csak egy programot kell/szabad futtatnia. A korlátozott shell-en kívül így még a.profile file is szükséges mivel ezen keresztül indítjuk majd a szükséges alkalmazást. A korlátozott shell nem engedi a következő műveleteket: Nem használható a cd parancs. Nem lehet megváltoztatni a PATH, ENV és SHELL rendszer változókat. Nem lehet használni a slash ( / ) karakter parancsokban és file nevekben, vagyis minden filenak az aktuális könyvtárban kell lennie.á Nem lehet átirányítást használni (> és >>). Fontos, hogy a korlátozott shell esetén a felhasználó ne a saját home könyvtárába kerüljön a belépés után. Ez úgy érhető el, hogy a.profile file a belépés után azonnal áthelyezi a felhasználót egy másik könyvtárba. Ha mégis a home könyvtárba kerülne a felhasználó a belépés után, akkor a felhasználó felül írhatja a.profile file-t, ami lényegében kontrollálja a tevékenységét. A.profile file felülírásával másik programot is eltudna indítani a felhasználó. A másik korlátozás, hogy a PATH legyen minimális, illetve a felhasználó ne tudjon írni a PATH-ban megadott egyik könyvtárba sem. Ezt azért kell elkerülni, mivel egy okos felhasználó így felülírhat egy futtatható file-t a sajátjával és kitörhet a korlátozásból! Ezekre a problémákra általában azt a megoldást szokták választani, hogy a felhasználó home könyvtárában egy rbin könyvtárat hoznak létre amibe bemásolják az engedélyezett parancsokat és a PATH csak erre könyvtárra mutat. Minden esetben legyünk nagyon óvatosak, hogy milyen parancsokat engedünk futtatni egy korlátozott környezetben. Bizonyos parancsok megengedik azt, hogy bármilyen shell parancsot futassunk le (shell escape). Például a vi programban: :!parancs módszer használható. Ugyanígy az ártatlannak tűnő more és man programok is megengedik tetszőleges shell parancs végrehajtását Inicializáló file-ok A felhasználói fiókok létrehozása során a felhasználó home könyvtárába átmásolódnak a file-ok és könyvtárak az /etc/skel könyvtárból. Általában a file-ok között vannak a shell inicializáló file-jai is. Bourne shell :.profile C shell :.login,.logout,.cshrc Bourne again shell (bash) :.profile,.bash_profile,.bash_login,.bash_logout és.bashrc A file-ok azért kezdődnek a pont karakterrel, mivel ezeket a file-okat az ls parancs speciális kezeli és csak bizonyos (-a) kapcsoló megadásával nyomtatja ki. A file-ok shell scriptek. Minden belépés során 30

31 lefutnak a következő file-ok:.profile,.login,.bash_profile,.bash_login. Minden új shell elindítása során a.cshrc és.bashrc file-ok futnak le, illetve kilépéskor a.logout és.bash_logout scriptek. Egy példa.profile file a következő lehetne: umask 022 mesg y PATH=$PATH:/usr/local/bin:$HOME/bin:. EDITOR=vi MORE=-c PS1=" hostname -\!> " export PATH EDITOR MORE PS1 A különböző grafikus desktop alkalmazások is használnak inicializáló file-okat, melyek szintén a felhasználók home könyvtárába kerülnek. Az X Window rendszer inicializáló szokásos file-ja:.xinitrc,.xsession és.xauthority. A Common Desktop Environment (CDE) inicializáló file-ja a.dtprofile illetve a további file-okat tartalmazó könyvtár a /.dt Rendszerszintű inicializáló file-ok Az sh és bash shell-ek esetén az /etc/profile file mint egy rendszerszintű inicializáló fileként szolgál, vagyis a felhasználó saját inicializáló file-ja előtt lefut. Ebben a file-ban szinte mindig definiálva van a PATH környezeti változó. Ha ezt a file-t szeretnénk módosítani a legjobb módszer az, hogy egy másik file-t hozunk létre, például: /etc/profile.local, és ezt a file-t futtatjuk le a /etc/profile-ban. Ezt azért érdemes ilyen módon megoldani, mert egy későbbi frissítés az /etc/profile file-t felülírhatja, így csak a hivatkozást veszítjük el, ami könnyen helyreállítható, de maguk a beállítások megvannak a /etc/profile.local file-ban login.defs file Az /etc/login.defs file tartalmaz olyan beállításokat amelyek általában a login folyamatra, a felhasználó belépésére vonatkoznak. A file-ban talán a következők a legfontosabb beállítások: FAIL_DELAY 10 : várjon 10 szekundumot a bejelentkezés próbálkozások között. LOGIN_RETRIES 5 : a bejelentkezési próbálkozások maximális száma LOGIN_TIMEOUT 30 : hány másodpercig várjon a rendszer a jelszóra FAILLOG_ENAB yes : rögzítse a bejelentkezési próbálkozásokat a /var/log/faillog file-ba LASTLOG_ENAB yes : rögzítsen minden bejelentkezést a /var/log/lastlog file-ban DEFAULT_HOME yes : engedje a bejelentkezést akkor is, ha a felhasználó home könyvtára nem elérhető UID_MIN 100, UID_MAX : az UID minimális és maximális értéke GID_MIN 100, GID_MAX 2000 : a GID minimális és maximális értéke 31

32 4.15 Jelszavak Mivel a jelszavak kulcs fontosságúak az operációs rendszer biztonsága szempontjából, ezért nagyon fontos, hogy minden felhasználónak legyen jelszava. Ugyanakkor ez nem elegendő, mert arra is szükség van, hogy a jelszót ne lehessen kitalálni. Ezért ebben a fejezetben a jelszavakkal foglalkozunk egy kicsit részletesebben. A jó jelszóra könnyű emlékezni, de nehéz kitalálni illetve feltörni. Sajnos az automatikan, véletlenszerűen generált jelszavak ellentmondanak a fenti elvnek, hogy könnyű legyen rájuk emlékezni. A legtöbb felhasználó az ilyen jelszavakat könnyen elfelejti, így általában le szokták írni, ami kifejezetten ellentmond a jelszó titkosságának. Az egyik módszer ennek a problémának az elkerülésére, hogy engedjük, hogy a felhasználó adja meg a jelszavát. Ugyanakkor a felhasználót fel kell készíteni arra is, hogy milyen is egy jó jelszó. Például amit kerülni kellene, mivel könnyű kitalálni: A kereszt vagy vezetéknév használata, vagy családtag nevének használata. Az édesanya leánykori nevét elég könnyű megszerezni, így az sem jó. A felhasználó jellegzetes számai sem jók: személyi szám, TB szám vagy adóazonosító, születési dátum, telefonszám, kocsi rendszámtáblája. A felhasználónak fontos dolgok: kedvenc étel, kedvenc énekes, TV színész, sportoló, stb. A jelszónek a számítógépes feltörési kísérleteknek is ellen kell tudni állni, így szintén nem javasoltak a következők: angol vagy egyéb nyelvben előforduló szavak helyesen írva, mivel ezek a különböző on-line szótárakban megtalálhatók, rövidített szavak, híres emberek, helyek, az Interneten publikált példa jelszavak. A fenti szavak akkor sem jók, ha fordítva írjuk le őket, egy betűt vagy számot hozzáfűzűnk, esetleg a betűk valami egyszerű permutációját használjuk. Például nem jó: john, john2, nhoj. Ez azért van így, mivel a jelszó kitaláló, feltörő programok ezeket a kombinációkat nagyon könnyen kitalálják. A második listában felsorolt szavak bár önmagukban nem jók, de a következő variációkkal biztonságosabb jelszót kaphatunk: A szó közepébe egy vagy két speciális karakter beillesztése. Különösen jó, ha ez a karakter valamilyen speciális jel: kettőspont, felkiáltó jel, stb. A szó helytelen írásmóddal. Szokatlan nagy és kis betű kombináció: startrek. Az nem jó, minden csupa kis vagy nagy betű, vagy minden magánhangzó azonos, például rossz: startrek, STARTREK, STaRTReK. Kettő vagy több szó összefűzve. Egy szó beágyazása egy másik szóba, például: macskutyaa. Két vagy több szó egymásba fűzése Egy másik módszer, hogy egy mondatban előforduló szavak első betűinek összefűzése is egy jó jelszót adhat, például: Harminc két éves lettem én, meglepetes e költemény 32

33 amiből a jelszó: hkele,mek Minden esetre a lényeg, hogy a jelszót nehéz lehessen kitalálni Jelszavak és felhasználói fiókok Néhány további tanács a jelszavakkal kapcsolatban: Minden felhasználói fióknak legyen jelszava. Amikor egy felhasználó nem használja többet a gépet, előként mindig zárjuk le (lock) a felhasználói fiókot. A rendszeren határozzuk meg, hogy minimum hány karakterből álljon a jelszó. minimum 8 szokott lenni. Általában ez A jelszót mindig meg kell változtatni, ha: A felhasználón kívűl valaki más is ismeri a jelszót. A felhasználó elmegy a cégtől, minden általa ismert jelszót meg kell változtatni. Amikor a rendszer adminisztrátor elmegy a cégtől, a root jelszavát és minden rendszer jelszót meg kell változtatni. Ha akarjuk a felhasználókat is kényszeríthetjük jelszó váltásra, mivel a root ismeri az összes kódolt jelszót. Amikor a rendszer adminisztrátort kirugják, minden jelszót meg kell változtatni, mivel a root ismeri az összes kódolt jelszót! Amikor azt sejtjük, hogy a shadow-t valaki más is el tudta olvasni. A root jelszavát időről időre érdemes megváltoztatni. Természetesen nem kell minden rendszer adminisztrátornak naponta változtatni a jelszavát, de azért ha gyanakszunk valamire érdemes megváltoztatni. A felhasználók esetén érdemes valamilyen stratégiát megfogalmazni. Például, hívjuk fel a felhasználó figyelmét, hogy ezen a rendszeren ne ugyanazt a jelszót használja, mint más gépeken. Jelszóváltás kezdeményezése A Linux rendszereken a chage parancs használható a jelszóváltás kezdeményezésére. Ugyanakkor ez a parancs a jelszavak öregedésével kapcsolatos, amit pedig a shadow file-ban adhatunk meg. A parancs egyik lehetséges formája: $ chage -d 0 -M 999 user ahol a -d opcióval azt adjuk meg, hogy az utolsó jelszóváltás 1970 január 1-én volt (0 nap telt el) és a -M opció pedig meghatározza, hogy a jelszó maximális élettartama 999 nap. Figyelem ez az utóbbi kapcsoló felülírja a jelszó öregedési paramétereket! Jelszó öregedés, elavulás Mielőtt bekapcsolnánk a periódikus jelszóváltást, vagy a jelszavak öregedését elavulását, fontoljuk meg, hogy mennyire akarunk szigorúak lenni. A felhasználókat sűrűn arra kényszeríteni, hogy váltsanak jelszót eléggé felbosszanthatja őket. A jelszó elavulás paramétereit a shadow file-ban lehet megadni, mint korábban láttuk: 33

34 username:jelszó:utolsó-vált:minlife:maxlife:warn:inactive:lejár:nem-használt A 3. mező adja meg a jelszó utolsó megváltoztatása óta eltelt napok számát (1970. január 1- jétől kezdődően). Ha nullára állítjuk és a maxlife kisebb mint a január 1 óta eltelt napok száma, akkor a következő bejelentkezésnél a felhasználónak meg kell változtatnia a jelszavát. Ezután következik (minlife) azon napok száma, amiután legkorábban a felhasználó megváltoztathatja a jelszavát, amit azon napok száma (maxlife) követ, amin belül mindenképpen meg kell változtatni a jelszót. Ezt követik a figyelmeztetésre vonatkozó beállítások. A 6. mezőben (warn) állíthatjuk be, hogy a kötelező jelszóváltás előtt hány nappal kapjon figyelmeztető üzenetet a felhasználó. A 7. mező türelmi időt határoz meg, vagyis a kötelező jelzóváltás után még hány napig engedjük a felhasználónak a rendszert használni. Ha a felhasználó ez idő alatt sem végzi el a jelszóváltást, akkor letíltja a rendszer a hozzáférést. A 8. mező mutatja a felhasználó letíltásának idejét (1970. január 1-jétől kezdődően). A -1 -es érték egy mezőben azt jelenti, hogy soha. Az egyes paraméterek beállítására alkalmas parancsok: Minimum élettartam : chage -m napok user Maximum élettartam : chage -M napok user Figyelmeztetési idő : chage -w napok user Inactive periódus : chage -I napok user Expire periódus : chage -E napok user Utolsó jelszóváltás ideje : chage -d napok user Jelszó elavulási paraméterek kiírása : chage -l user Nézzük meg mit ír ki a rendszer a jelszó elavulásról: $ chage -l root Last password change: Sep 26, 2009 Password expires: never Password inactive: never Account expires: never Minimum number of days between password change: 0 Maximum number of days between password change: Number of days of warning before password expires: Jelszavak kitalálása John the Ripper és Crack programok használhatók arra, hogy automatikusan próbáljuk megkeresni egy kódolt jelszónak megfelelő kódolatlan jelszót. A programok próbálgatást használ. A programok a szavakat szabályok alapján generálják vagy szótárakból veszik. 34

35 5. Fejezet PAM rendszer Hagyományosan a Unix rendszereken az autentikáció vagy felhasználó azonosítás csak egyszer történt meg, a bejelentkezés, a login, során. Ugyanakkor több olyan alkalmazás is van, amelyik ismételt felhasználó azonosítást igényel, például a jelszó megváltoztatása. A korábbi Unix verziók ilyenkor az /etc/passwd file-t olvasták. Ez problémát jelentett, amikor valami változás volt a file formátumában, vagy újabb autentikációs eljárást akartak integrálni a rendszerbe. Például shadow file bevezetése, integráció NIS rendszerekkel, MD5 titkosítás, és LDAP autentikáció. Minden ilyen változás esetén speciális módosítást igényelt, és minden kapcsolódó programot újra kellett fordítani. Erre a probléma jelentett megoldást a PAM rendszer bevezetése. A PAM jelentése: Pluggable Authentication Module. A PAM rendszer ma már szinte minden Unix alatt megtalálható: FreeBSD, HP-UX, Solaris és Linux. A PAM rendszer célja egy flexibilis és konfigurálható mechanizmus biztosítása a felhasználók azonosítására, függetlenül a különböző programoktól. Így a programokat bármilyen autentikációtól, eljárástól függetlenül lehet fejleszteni, vagyis a programokban nem kell előre meghatároznunk, hogy milyen felhasználói autentikációt akarunk majd használni. A rendszer úgy működik, hogy a futás során dinamikusan töltődnek be a szükséges modulok. Ha szeretnénk megnézni, hogy egy program használja-e a PAM rendszert, akkor azt kell megvizsgálnunk, hogy a program használja-e a PAM rendszer fejlesztői könyvtárát: $ ldd which passwd grep pam libpam.so.0 => /lib/libpam.so.0 (0xb7f28000) ahol az ldd parancs kinyomtatja a megosztott (shared) könyvtárakat amiket egy program használ. A felhasználói azonosításon kívűl a PAM rendszer képes más feladatok elvégzésére, például loggolásra vagy a napi üzenet megjelenítésére. Ezeken felül a PAM rendszer a beléptetés során nem csak a jelszót, hanem más feltételeket is képes ellenőrizni, például az erőforrás rendelkezésre áll-e, nincsennek-e túl sokan bejelentkezve. 5.1 Konfiguráció A PAM rendszert szöveges konfigurációs file-okon keresztül lehet beállítani. A file lényegében azon modulok listáját tartalmazza, amikre szükség van az autentikáció során. Ezt szokták stack-nek nevezni. Amikor egy programnak egy felhasználót azonosítania kell, akkor a konfigurációs file-ban megadott sorrendben meghívja a modulokat. Minden modul visszatér egy értékkel: engedélyezett (success) vagy tiltott (failure) státuszt jelezve. Ezeket kombinálja össze a rendszer egy eredménnyé. Ezt a kombinációt befolyásolja a kontroll paraméter. Általában ha egy modul tiltja a hozzáférést, akkor a PAM rendszer értesíti az alkalmazást, hogy a hozzáférés megtagadva (access denied) az alkalmazás számára. Természetesen ez a működés felülírható, hiszen például ha az elsőként végrehajtott LDAP azonosítás nem sikerül, akkor még megpróbálhatjuk a helyi file-okból azonosítani a felhasználót. 35

36 A konfigurációs file-ok általában az /etc/pam.d könyvtárban találhatók. Ebben a könyvtárban a különböző alkalmazásokhoz tartozóan különböző file található. Például az su alkalmazás esetén az /etc/pam.d/su file tartalmazza a beállításokat. Ha az alkalmazáshoz nincs file ebben a könyvtárban, akkor az other file tartalma vonatkozik rá. Biztonsági szempontból fontos, hogy létezzen ez a file és például az alap stratégia az legyen, hogy megtagadja a hozzáférést. Ezeknek a konfigurációs fileoknak a segítségével tudjuk az alkalmazások hozzáférési policy-ját megadni, de ugyanakkor nem szabad elfelejteni, hogy egyéb mechanizmusok is befolyásolják a hozzáférést: file jogosultságok, TCP wrapper, ACL-ek, és így tovább. A PAM modulok a /lib/security könyvtárban találhatók meg. Minden modul egy dinamikusan betölthető könyvtár, DLL, amelyek a PAM rendszer függvényeit hívják meg. A PAM rendszer függvényei és szolgáltatásai négy típusba, kontextusba sorolhatók: account : Ezeket a modulokat akkor használja a rendszer amikor azt kell ellenőrizni, hogy jogosult-e az adott szolgáltatást elérni a felhasználó. auth : Ezeket a modulokat akkor használja a rendszer amikor azt kell ellenőrizni, hogy a felhasználó tényleg az akinek mondja magát. password : Ezeket a modulokat akkor használja a rendszer amikor az autentikációs mechanizmust frissíteni kell, például új jelszót akarunk megadni. session : Ezeket a modulokat akkor használja a rendszer mielőtt az adott szolgáltatást elindítaná, vagy leállítaná. Például loggolás, felhasználói könyvtár becsatolása. Egy konfigurációs file sorokból áll és minden sor négy részből állhat: típus kontroll_paraméter modul modul_paraméterek Üres sorok és megjegyzések megengedettek. A megjegyzés sorok a # karakterrel kezdődnek. Az első bejegyzés a sorokban a típust adja meg, a második pedig a kontroll paraméter Kontroll paraméterek A kontroll paraméter lehetséges értékei: sufficient : Ha az adott modul engedélyezi a hozzáférést, akkor minden további modul átugorható és összeségében is engedélyezzük a hozzáférést. Ezzel szemben, ha a modul nem engedélyezi a hozzáférést, az nem jelenti azt, hogy véglegesen tiltott a hozzáférés mivel ha egy későbbi sufficient vagy required modul engedélyezi akkor összeségében is engedélyezve lesz a hozzáférés. requisite : Ha az adott modul tiltja a hozzáférést, akkor minden további modul átugorható és összeségében is tiltjuk a hozzáférést. required : Az adott modulnak engedélyeznie kell a hozzáférést, hogy összeségében is engedélyezve legyen, de nem elegendő ez az egy engedélyezés. Vagy egy későbbi sufficient modulnak engedélyeznie kell a hozzáférést vagy minden későbbi required modulnak. Ha bármlyik required modul tiltással tér vissza attól még a többi required modul is lefut, így a rosszindulatú emberek nem fogják tudni, hogy mely azonosítási lépés nem sikerült. optional : Ennek a modulnak a visszatérési értékét csak akkor használja a rendszer, ha a többi modul alapján nem meghatározható az engedélyezés vagy tiltás. A modulok sorrendje is fontos! Ha egy required modul sikertelen és egy későbbi sufficient modul sikeres, attól még a hozzáférés sikertelen lesz! Például: 36

37 auth required pam_modulea auth sufficient pam_moduleb auth required pam_modulec ez egy olyan stratégiát valósít meg, hogy csak akkor engedélyezett a hozzáférés, ha: pam_modulea és pam_moduleb is engedélyezi a hozzáférést vagy pam_modulea és pam_modulec is engedélyezi a hozzáférést. Mi történik ha felcseréljük az első két sort? auth sufficient pam_moduleb auth required pam_modulea auth required pam_modulec Ebben az esetben a hozzáférés akkor sikeres ha: pam_moduleb engedélyezi a hozzáférést vagy pam_modulea és pam_modulec is engedélyezi a hozzáférést Modul visszatérési érték Valójában a PAM rendszeren belüli modulok nem csak az engedélyezett és tiltott értékekkel tudnak visszatérni, mivel paramétereken keresztül megadható más érték is. A régebbi PAM rendszerek csak két értéket használtak, az újabb rendszer már több mint 30 féle visszatérési értéket is tud kezelni. Az új szintakszis: típus [érték=akció érték=akció...] modul opciók ahol az érték a következő lehet: ABORT : kritikus hiba, azonnal véget ér ACCT_EXPIRED : felhasználói fiók lejárt AUTHINFO_UNAVAIL : autentikációs információ nem lekérhető az autentikációs szolgáltatástól AUTHTOK_DISABLE_AGING : autentikációs token elavulási módszer kikapcsolva AUTHTOK_ERR : autentikációs token módosítási hiba AUTHTOK_EXPIRED : autentikációs token lejár AUTHTOK_LOCK_BUSY : autentikációs token zárolás nem lehetséges AUTHTOK_RECOVERY_ERR : autentikációs információt nem lehetett megszerezni AUTH_ERR : autentikációs hiba BUF_ERR : memória buffer hiba CONV_ERR : kommunikációs hiba CRED_ERR : CRED_EXPIRED : CRED_INSUFFICIENT : 37

38 CRED_UNAVAIL : IGNORE : ennek a modulnak a visszatérési értékét ne vegye figyelembe a PAM rendszer INCOMPLETE : MAXTRIES : az adott szolgáltatás felé történő próbálkozások maximális számát meghaladtuk MODULE_UNKNOWN : ismeretlen modul NEW_AUTHTOK_REQD : autentikációs token többé már nem érvényes, egy újra van szükség NO_MODULE_DATA : semmilyen modul specifikus adat nem áll rendelkezésre OPEN_ERR : nem sikerült betölteni a modult PERM_DENIED : jogosultság megtagadva SERVICE_ERR : hiba a szolgáltatás modulban SESSION_ERR : nem lehet készíteni vagy eltávolítani a session-re vonatkozó bejegyzést SUCCESS : sikeres visszatérés SYMBOL_ERR : szimbólum nem található SYSTEM_ERR : rendszer hiba USER_UNKNOWN : a felhasználó nem ismert az autentikációs modul számára default : minden visszatérési érték ami nincs explicit módon felsorolva Az akció néhány lehetséges értéke: ok : Ha az eddig végrehajtott modulok visszatérési értékeinek kombinált értéke engedélyezést jelent akkor az aktuális modul visszatérési értéke felülírja ezt az értéket. (Ez lényegében a required kontroll paraméternek felel meg, amikor a modul engedélyezéssel tér vissza.) Ha az eddigi kombinált érték tiltás, akkor ezt az értéket nem használja a rendszer. done : Az ok akciónak felel meg, de azonnal befejezi a stack végrehajtását és visszatér a hívó alkalmazáshoz. (Ez lényegében a sufficient kontroll paraméternek felel meg.) bad : Azt jelzi, hogy a stack visszatérési értéke a tiltás legyen. (Ez lényegében a required kontroll paraméternek felel meg, amikor a modul tiltással tér vissza.) die : Tiltást jelent és azonnal befejezi a stack végrehajtását. (Ez lényegében a requisite kontroll paraméternek felel meg.) ignore : A modul visszatérési értéke nem számít bele az alkalmazásnak adott visszatérési értékbe. reset : Törölje a stack eddigi végrehajtásából származó értékeket. n : Ugorja át a következő n modult. A hagyományos kontroll paraméter értékeket, az új formában, a következőképpen lehet megadni: required : [success=ok new_authtok_reqd=ok ignore=ignore default=bad] 38

39 requisite : [success=ok new_authtok_reqd=ok ignore=ignore default=die] sufficient : [success=done new_authtok_reqd=done default=ignore] optional : [success=ok new_authtok_reqd=ok default=ignore] Példák 1. Nézzünk meg egy képzeletbeli példa file-t: auth sufficient pam_rootok.so auth sufficient pam_timestamp.so auth required pam_unix.so shadow nullok account required pam_permit.so session required pam_permit.so amit a következőképpen lehet értelmezni: auth sufficient pam_rootok.so ez azt jelenti, hogy ha a felhasználó root, az már önmagában is elegendő (sufficient) az autentikációhoz. Ha a felhasználó nem root, akkor a következő sort is meg kell vizsgálni: auth sufficient pam_timestamp.so Ez a modul azt biztosítja, hogy az autentikálásokat egy cache-ben tárolja a rendszer és ezeket újra tudja hasznosítani. Alap esetben az 5 percen belüli azonosítást a rendszer elegendően (sufficient) elfogadja. A harmadik sor auth required pam_unix.so shadow nullok azt jelenti, hogy jelszót kérünk a felhasználótól. Ha jó jelszót adott meg a felhasználó, akkor engedélyezi a hozzáférést, egyébként tiltja. A shadow paraméter azt jelenti, hogy a rendszer használja a shadow file-t, míg a nullok paraméter azt engedélyzi, hogy az üres jelszó is elfogadott. Ha ezt a paramétert töröljük, akkor lényegében letiltjuk azokat a felhasználói fiókokat, amelyekhez nincs jelszó rendelve. A pam_permit.so modul nagyon egyszerű, mivel mindig engedélyezi a hozzáférést. Viszont az is látható, hogy a pam_permit.so modult az account és session típusú soroknál is használtuk. Ez több modulra is jellemző, hogy attól függően milyen típusú sorban használjuk, másképpen viselkedik. 2. Nézzünk egy valóságos példát: 39

40 auth requisite pam_securetty.so auth requisite pam_nologin.so auth sufficient pam_rhosts_auth.so auth required pam_unix.so account required pam_unix.so account required pam_time.so password required pam_cracklib.so retry=3 \ type=unix minlen=10 ocredit=2 \ dcredit=2 password required pam_unix.so use_authok shadow md5 session required pam_unix.so session optional pam_motd.so motd=/etc/pmotd Az első sor megtagadja a hozzáférést, ha a felhasználó root és olyan terminálon próbál bejelentkezni, amelyik nem biztonságos, vagyis nem szerepel a /etc/securetty file-ban. A második sorban megadott modul akkor nem enged hozzáférést ha létezik a /etc/nologin file. Ha létezik a file, akkor a tartalma megjelenik a képernyőn és a rendszer megtagadja a hozzáférést. A 3. sorban az pam_rhosts_auth.so modul azt vizsgálja meg, hogy a /etc/rhosts.equiv mechanizmus engedi-e a belépést. Végül a 4. sor bekéri a felhasználó jelszavát. Ha az autentikáció (auth) sikerült, akkor jön az account rész. Először itt is a jelszó kerül ellenőrzésre, például ellenőrzi, hogy a felhasználói fiók nem járt le, a jelszót nem kell-e megváltoztatni. A pam_time.so modul ellenőrzi a konfigurációs file-jában, hogy az adott felhasználónak szabade belépnie az adott időben. Ebből a két modulból egyik sem tilthatja a hozzáférést, ha tényleg be akarunk lépni. A password rész ellenőrzi az új jelszót a crack program segítségével, majd MD5-ös kódolást használva a shadow file-ban tárolja el a jelszót. Végül az utolsó előtti sor egy bejegyzést tesz a log file-ba és az utolsó sor kiírja a nap üzenetét. 3. Általában a PAM rendszer konfigurációs file-jai általában lineárisak, például: Azonosítsuk a felhasználót LDAP-ból. Ha nem megy akkor a lokális file-okból. De mi van akkor ha komplexebb dolgot szeretnénk megadni, például valamilyen feltételt szeretnénk beépíteni: Ha a felhasználó guest, akkor használjuk a pam_dbus modult egyébként a pam_unix modult. A megoldás valami hasonló lenne: auth [default=2 success=ignore] pam_succeed_if.so quiet user = guest auth [success=ok new_authtok_reqd=done ignore=ignore default=die] pam_dbus.so auth [default=1] pam_permit.so auth required pam_unix.so ahol az első sorban a pam_succeed_if.so ellenőrzi, hogy a felhasználó guest-e és ha igen, akkor ennek a modulnak az eredménye nem kell és folytassuk a következő sorban. Ha más a felhasználó, más értékkel tér vissza a modul, akkor ugorjunk át 2 sort és a 4. sorban folytassuk. A 2. sorban végezzük a hozzáférés ellenőrzést a guest felhasználó esetén, majd a 3. sorban átugorjuk a 4. sort! Lényegében egy if... then... else... szerkezetet valósítottunk meg a fenti példában. 4. Ez példa az előzőhöz nagyon hasonló, de ebben a példában a guest felhasználó mindig be tud jelentkezni! auth [default=2 success=ignore] pam_succeed_if.so quiet user = guest auth required pam_permit.so auth [default=1] pam_permit.so auth required pam_unix.so Az 1. sor ellenőrzi, hogy mi a felhasználó neve. A 2. sor engedélyezi a hozzáférést, míg 3. sor egy ugró utasításnak felel meg. A 4. sor csak akkor fut le, ha az első sor hamis volt. 40

41 5.2 Az other konfigurációs file A PAM rendszer azt is bitosítja, hogy ha egy alkalmazáshoz nem tartozik konfigurációs file, akkor az /etc/pam.d/other file tartalmát fogja figyelembe venni. A tipikus tartalma a következő szokott lenni: auth required pam_warn.so auth required pam_deny.so Ennek hatására megjelenik egy figyelmeztető üzenet, hogy az alkalmazás nincs konfigurálva a PAM rendszerben és megtagadja az autentikációt. 5.3 PAM modulok Sajnos a modulokkal azért óvatosnak kell lenni, mivel a különböző Unix rendszereken a modulok egy picit másképpen működhetnek. Ezért mindig ellenőrizzük a PAM rendszer dokumentációját az adott rendszeren. Azt is fontos tudni, hogy a modulok alap beállításai nem mindig a legbiztonságosabbak. Az alábbi bekezdések csak a legfontosabb, illetve a leggyakrabban használt modulokat sorolja fel pam unix.so 5.4 Azonosítás USB eszközzel Arra is lehetőség van, hogy egy USB eszközt használjunk felhasználó azonosításra. Ez azért lehet hasznos, mert ebben az esetben egy hardware eszköz azonosítja a felhasználót, tehát akinék az eszköz van az a rendszer az adott felhasználót testesíti meg. Ebben az esetben az USB eszköz egyedi azonosítója szolgál majd autentikációképpen. Először is installáljunk fel két csomagot: $ apt-install install libpam-usb pamusb-tools Figyelem ezek a csomag X Window rendszert is installálnak, amiket ha nem akarjuk nem kell feltenni, mivel csak ajánlott csomagok. A rendszer konfigurálása igen egyszerű, csak a pamusb-conf parancsot kell használni: # pamusb-conf --add-device MyDevice Please select the device you wish to add. * Using "SanDisk Corp. Cruzer Titanium (SNDKXXXXXXXXXXXXXXXX)" (only option) Which volume would you like to use for storing data? * Using "/dev/sda1 (UUID: <6F6B-42FC>)" (only option) Name : MyDevice Vendor : SanDisk Corp. Model : Cruzer Titanium Serial : SNDKXXXXXXXXXXXXXXXX Volume UUID : 6F6B-42FC (/dev/sda1) Save to /etc/pamusb.conf? [Y/n] y Done. ahol a MyDevice név bármi lehet. Több eszköz is hozzáadható a rendszerhez. Az eszközhöz tartozó felhasználók ugyanilyen könnyen hozzáadhatók a rendszerhez: 41

42 # pamusb-conf --add-user root Which device would you like to use for authentication? * Using "MyDevice" (only option) User : root Device : MyDevice Save to /etc/pamusb.conf? [Y/n] y Done. Ha ellenőrizni akarjuk, hogy minden rendben akkor a pamusb-check parancsot kell használni: # pamusb-check root * Authentication request for user "root" (pamusb-check) * Device "MyDevice" is connected (good). * Performing one time pad verification... * Verification match, updating one time pads... * Access granted. Végül magát a PAM rendszert kell beállítani, hogy használja az USB eszközöket is autentikációra. Az /etc/pam.d/common-auth file-ban keressük meg azt a sort amiben a pam_unix.so modul szerepel és a felette levő sorba helyezzük be a következőt: auth sufficient pam_usb.so auth required pam_unix.so nullok_secure Mindezek után, ha az eszköz csatlakoztatva van a számítógéphez, és beléptünk egy felhasználóként, akkor próbáljunk meg root felhasználóra váltani: $ su * pam_usb v.svn * Authentication request for user "root" (su) * Device "MyDevice" is connected (good). * Performing one time pad verification... * Verification match, updating one time pads... * Access granted. 5.5 Összegzés A PAM rendszer egy elég összetett és bonyolult rendszer, ezért fontos, hogy megértsük, hogyan lehet helyesen használni a biztonsági policy-k megadására. További információ a web oldalon található. 42

43 6. Fejezet Name Service Switch Wikipédia alapján. Egyes C függvényeknek vagy Unix segédprogramoknak, szüksége lehet bizonyos adatokra a környezetből, hogy korrekten működhessenek (pl. jelszó, gépnév,...). Korábban ezen adatok meghatározott fájlokban voltak eltárolva (pl. /etc/passwd) többnyire fixen meghatározott keresési helyen és sorrendben. A GNU C programkönyvtár megoldása erre (a Solaris 2, C könyvtár mintájára), hogy a rendszer adatbázisokat különböző modulokon keresztül lehet elérni. A lehetséges modulok megtalálhatók a /lib könyvtárban libnss_modulnév.so.x néven (compat, dns, files, ldap, nis, nisplus, wins, winbind). Az NSS által, új szolgáltatásokat lehet felvenni a C programkönyvtár módosítása nélkül, minden szolgáltatás esetén külön be lehet állítani (/etc/nsswitch.conf), hogy mely adatbázisokban keressen és milyen sorrendben. NSS-ből elérhető adatbázisok: aliases, ethers, group, hosts, netgroup, networks, protocols, passwd, rpc, services, shadow, automount, bootparms, netmask, publickey. 43

44 44

45 7. Fejezet FTP 45

46 46

47 8. Fejezet MySQL adatbázis 8.1 Bevezetés A MySQL adatbázis kezelő rendszer az msql (mini SQL) rendszerből fejlődött ki és az volt a fő cél, hogy legalább ugyanolyan gyors legyen. További célok voltak a robusztusság és könnyű használhatóság, így egy több-szálas (multi-threaded) programot készítettek. A több szál lehetővé teszi, hogy egy szál egy kapcsolatot, lekérdezést szolgáljon ki vagy egyszerre többen olvassanak az adatbázisból. Ezzel módszerrel gyorsítani lehet az adatbázis olvasásokat, főleg akkor ha több processzoros gépen futtatjuk az adatbáziskezelőt. Ugyanakkor, a tábla típusától függően az írási műveletek több kevesebb ideig feltartják a szálakat. Amíg egy szál ír egy táblába addig minden más szálnak várnia kell ha ugyanahhoz a táblához akar hozzáférni. Ez a zárolás. Milyen további előnyei vannak a MySQL adatbáziskezelőnek: nyilt forráskódú és nyilt szabványokat támogat; sok programozási nyelvben lehet fejleszteni hozzá alkalmazást: C, C++, Java, Perl, Python, PHP, stb. és különböző karakterkészleteket támogat, így mindenféle nyelvű szöveget képes eltárolni. 8.2 MySQL architektúrája A MySQL architektúrája eltér más adatbáziskezelőktől. A program architektúrája az 8.1. ábrán látható. A legfelső szint nem egyedi, olyan mint más adatbázisrendszerben és ez a szint kezeli a kapcsolatokat, autentikációt és így tovább. Talán abban egyedi ez a rész, hogy minden kérést egy külön szál szolgál ki. Ráadásul a szálak cache-elve vannak, így nem kell őket létrehozni és megszüntetni minden kapcsolat esetén. A középső szint egyedi a MySQL-ben. A MySQL egy fa szerkezetet alakít ki a beolvasott és értelmezett (parse) kérésből, majd ezt többféle módon optimalizálja. Az optimalizálás jelentheti a kérés újraírását, a táblák olvasási sorrendjének megváltoztatását vagy a megfelelő index kiválasztását. Ezt az optimalizációt különböző javaslatokkal (hint) lehet befolyásolni. A tároló motorok (storage engine) befolyásolják az optimalizációt. Például az optimalizáló lekérdezi a tároló motor képességeit és hogy melyik művelet mennyi ideig tart amiket fel tud használni az optimalizálás során. A MySQL mielőtt bármit is csinálna egy kéréssel, megnézi, hogy nem szerepel-e a lekérdezés gyorstárban (query cache). A lekérdezés gyorstárban csak SELECT kérések és eredményeik tárolódnak. Ha valaki egy olyan SELECT kérést ad ki, ami már szerepel a gyorstárban, tehát valaki már kiadta, akkor a szervernek nem kell semmit sem csinálnia, csak a gyorstárban tárolt eredményt kell visszaadni. 47

48 Kliensek Kapcsolat és szál kezelés Lekérdezés cache Parser Optimalizáló Tároló motorok 8.1. ábra: MySQL architektúrája 8.3 Alapfogalmak Zárolás, locking Előfordulhat, hogy egyszerre két kérés is befut az adatbázis szerverhez melyek egyidőben akarják ugyanazt az adatot vagy táblát módosítani. Ezt a konkurrens hozzáférést ellenőrizni kell, általában valamilyen zárolást (lock) használnak. Két típusú zárolás van: shared lock és exclusive lock. Az olvasás zárolás megosztott (shared) típusú vagyis több kliens is olvashat egyszerre az adatbázisból anélkül, hogy zavarnák egymást. Ugyanakkor a írási zárolás exkluzív vagy kizáró jellegű, vagyis nem enged semmilyen más írási vagy olvasási műveletet végrehajtódni amíg az írás be nem fejeződik. Az adatbázisok kezelése során nagyon sokszor használja a rendszer a zárolást. Minden alkalommal ellenőrizni kell a zárolásokat, ha kell zárolja az adatokat, majd felszabadítja. Ebből is látszik, hogy jelentős extra munkát jelent az adatbázis kezelő számára. Ezen felül az is segítene az adatbázis kezelő sebességén, hogy ha minnél kevesebb adatot zárolunk, illetve csak azt amelyiket írjuk, így lokalizálva, leszűkítve a zárolást. A legtöbb adatbázis kezelő csak sor szintű zárolást biztosít, de a MySQL a tároló motorok segítségével többféle zárolási stratégiát képes megvalósítani Tranzakciók Fontos kérdés szokott lenni a tranzakció kezelés kérdése. A tranzakciók fontosak az alkalmazások számára, ha az adatokat komplex szabályok alapján egyszerre kell frissíteni, írni. Nem olyan túl rég óta léteznek tranzakciók a MySQL-ben, de csak akkor használhatók ha külön megadjuk a táblák létrehozásánál. Miért csak mostanában adták hozzá a rendszerhez a tranzakciókat? A sebesség miatt. Amint tranzakciókat használunk az adatbázis kezelése lassabb lesz. A tranzakció tulajdonképpen nem más mint olyan SQL utasítások csoportja, amiket egyben kell és lehet végrehajtani. Ha sikerül az SQL utasítás csoportot egyben végrehajtani, akkor az adatbázis ezt elfogadja, de ha bármelyik utasítás nem tud lefutni, vagy hibát generál, akkor egyiket sem alkalmazza az adatbáziskezelő rendszer. Ez egy mindent vagy semmit rendszer. Vegyünk egy példát. Egy bank adatbázisában két fő tábla van a checking és a savings számlák. Ha egy ember a checking számlájáról 200 Ft-ot szeretne áttenni a savings számlára, akkor: 48

49 először ellenőrizni kell, hogy van-e több mint 200 Ft a számlán, levonunk 200 Ft-ot a checking számláról és beteszünk 200 Ft-ot a savings számlára. SQL kifejezések formájában ez a következőképpen néz ki: 1 START TRANSACTION; 2 SELECT balance FROM checking WHERE customer_id = ; 3 UPDATE checking SET balance = balance WHERE customer_id = ; 4 UPDATE savings SET balance = balance WHERE customer_id = ; 5 COMMIT; A tranzakciók csak akkor működnek jól, ha teljesítik az ACID tesztet. Az ACID négy szó első betűjéből áll: Atomicity : A tranzakciónak atominak kell lennie, vagyis egy és oszthatatlan egységnek. Ebben az esetben nincs részben végrehajtott tranzakció. Consistency : Az adatbázis egyik konzisztens állapotból egy másik konzisztens állapotba kerül. Ez például azt jelenti, hogy a fenti példában a 200 Ft nem tünhet el és nem is keletkezhet ismeretlen forrásból. Isolation : Izoláció, vagyis egy tranzakció láthatatlan más tranzakciók számára addig amíg a tranzakció be nem fejeződik. Durability : Tartósság, vagyis ha egyszer egy tranzakció végrehajtódott akkor a változás végleges. Alkalmazásban elég nehéz ezeket a feltételeket biztosítani és a MySQL-nek is több komplikált műveletet kell végrehajtania, hogy biztosítsa az ACID feltételeket és ez okozza a sebesség csökkenést. Holtpont Az adatbázisok esetén holtpont (deadlock) akkor alakul ki amikor kettő vagy több tranzakció már zárolt valamilyen adatot és újabb adatot akar zárolni, amit viszont egy másik tranzakció már zárolt. Például, tranzakció 1: START TRANSACTION; UPDATE StockPrice SET close = WHERE stock_id = 4 and date = ; UPDATE StockPrice SET close = WHERE stock_id = 3 and date = ; COMMIT; illetve tranzakció 2: START TRANSACTION; UPDATE StockPrice SET high = WHERE stock_id = 3 and date = ; UPDATE StockPrice SET high = WHERE stock_id = 4 and date = ; COMMIT; Tegyük fel, hogy mindkét tranzakció végrehajtja a 2. sort és ezzel zárolnak egy-egy sort a táblában, de ezután olyan sort próbálnak módosítani, amelyiket már a másik tranzakció zárolt. Mivel a sorok zárolva vannak, ezért várniuk kell, a végtelenségig és így alakult ki a holtpont, mivel a rendszer nem tud előre lépni. A különböző tároló motorok különbözőképpen oldják meg a holtpont kezelést. Egyes tároló motorok feladják a tranzakció végrehajtását, ha egy bizonyos idő eltelt a végrehajtása során. Ugyanakkor az InnoDB tároló motor észreveszi a körkörös függőségeket és az egyik tranzakció hatását visszaállítja (roll back). 49

50 8.4 Adatbázis típusok A MySQL rendszer többféle tábla típust vagy tároló motort (storage engine) támogat. Minden létrehozott tábla definícióját a MySQL egy.frm kiterjesztésű file-ban tárol. Ha szeretnénk megállapítani, hogy egy tábla mely tároló motorral lett létrehozva a következő parancsot lehet kiadni: mysql> SHOW TABLE STATUS LIKE user \G *************************** 1. row *************************** Name: user Engine: MyISAM Row_format: Dynamic Rows: 6 Avg_row_length: 59 Data_length: 356 Max_data_length: Index_length: 2048 Data_free: 0 Auto_increment: NULL Create_time: :07:17 Update_time: :56:29 Check_time: NULL Collation: utf8_bin Checksum: NULL Create_options: Comment: Users and global privileges 1 row in set (0.00 sec) A fenti listában a user tábla tároló motorja a MyISAM. További tároló motorok listája: ISAM : Ez a tábla típus az 5.x MySQL változatban többé nem támogatott. Minden funkcionalitását a MyISAM tábla típus vette át. Az ISAM esetén a maximális tároló kapacitás 4 GB volt és nem volt hordozható. MyISAM : Ez az alapértelmezett tábla típus és csak táblánkénti zárolást támogat. Nagyon gyors tároló motor, de nem támogatja a tranzakciókat. A táblák mérete függ az operációs rendszertől de hordozhatóak rendszerről rendszerre. Maximum 64 kulcs lehet táblánként és a maximális kulcs hossz 1024 byte lehet. Két file-t hoz létre, egy.myd file-t ami az adatokat és egy.myi file-t ami pedig az indexet tartalmazza. Compressed MyISAM : Bizonyos esetekben elegendő olyan adatbázis amit csak olvasni kell és nem kell módosítani. Például az adatbázis egy CDROM-on vagy DVD-n található. Ebben az esetben jól használható ez a típus, mivel kisebb helyet foglal a tömörítés miatt. Ha mégis módosítani kell az adatokat, akkor először ki kell tömöríteni, majd módosítani kell az adatot és vissza tömöríteni. MyISAM Merge : Azért létezik ez a tábla típus, hogy több MyISAM táblát egyben lehessen kezelni, ezzel eltörölve a MyISAM táblák méretkorlátát. InnoDB : Biztonságosan valósítja meg a tranzakciókat és a soronkénti zárolást (lock) is támogatja. Idegen kulcsok is támogatottak. Egy InnoDB tábla több file-ban is tárolható így a tábla méretét csak a merev kapacitása korlátozza. Ezek az adattáblák is hordozhatók rendszerről rendszerre. Egy hátránya ennek az adatbázisnak, hogy több helyet foglal mint az MyISAM tábla formátum. Memory : Régebben Heap típusnak nevezték. Ezek a táblák a memóriában tárolódnak, így ez a leggyorsabb tábla típus, de áramszünet esetén az adatok elvesznek. A táblák nem támogatják az AUTO INCREMENT tulajdonságot és BLOB, TEXT adattípusokat. 50

51 Archive : Ez a tároló motor csak az INSERT és SELECT utasításokat támogatja. Nincsennek indexek. Kevesebb lemez I/O műveletet igányel mint a MyISAM motor. Minden SELECT műveletnek a teljes táblát át kell olvasnia, így főleg loggolásra, vagy mérési adatok tárolására alkalmas, mivel az analízis során is a teljes táblát végig kell olvasni. Soronkénti zárolást használ és speciális bufferelést használ, hogy az adatokot gyorsan lehessen beilleszteni. CSV : Ez motor CSV (Comma Separated Values) file-okat tud táblaként kezelni. Jól használható a táblázatkezelő programokkal együtt, hiszen azok file formátumát azonnal fel tudja dolgozni, be tudja tölteni. Federated : Ez a tároló motor minden adatot egy távoli szerveren tárol. Semmilyen adatot nem tárol lokálisan, mivel minden Federated tábla egy távoli MySQL táblára hivatkozik és minden művelet során a távoli szerverhez kapcsolódik. Több furcsaság és korlátozás jár ezzel a tároló motorral. Blackhole : Más néven fekete lyuk tároló motor. Ez a motor nem veszi figyelembe az INSERT utasításokat. Ugyanakkor minden műveletet tárol a logokban és így az adatbázisok speciális replikációjában lehet hasznos. (Lásd fejezet) NDB Cluster : Ezt a tároló motor a 2003-ban, a Sony-tól megvett technológiára épül és a kluszteres megoldásoknál játszhat szerepet. BerkeleyDB (BDB) : Hasonló az InnoDB típushoz és támogatja a tranzakciókat. Támogatja a lap szintű zárolást de az adat file nem hordozható. A fent felsorolt tároló motorokon kívül még vannak továbbiak, amiket itt most nem tárgyalunk. Ha valami speciális igény van akkor érdemes azok használatát is megfontolni Tároló motor választás Amikor megtervezzük az alkalmazásunket, amelyik MySQL adatbázist fog használni, érdemes megfontolni, hogy melyik tároló motort használja majd az alkalmazás. Ráadásul táblánként különbözőt lehet használni, így erre is figyelni kell. Néhány szempont a választáshoz: Tranzakció : Ha az alkalmazásnak szüksége van tranzakciókra, akkor a legstabilabb és legjobb tároló motor az InnoDB. Ha nem kellenek tranzakciók és általában SELECT és INSERT utasításokat használunk, akkor a MyISAM egy jó választás. Konkurrencia : Ha csak egyszerű beillesztést és kiválasztást akarunk használni, akkor a MyISAM típus elegendő. Komplexebb műveletek keveréke esetén a sor zárolást használó táblák egyike jobb lehet. Hiba utáni helyreállítás : Ha sok adatunk van, akkor érdemes azt is megfontolni, hogy mennyi ideig tartana az adatok helyreállítása. A MyISAM típus általában könnyebben lesznek hibásak és tovább tart a helyreállítás. Az InnoDB motor sokkal gyorsabban tudja az adatokat helyreállítani. Általában ez a fő ok, hogy az emberek miért az InnoDB motort választják még akkor is ha nincs szükségük tranzakcióra. Speciális szolgáltatások : Ha kluszteres indexre van szükségünk akkor csak az InnoDB motort választhatjuk. Vagy csak a MyISAM motorral lehetséges a teljes adatbázisban a szöveges keresés. 8.5 Manuális installálás Ebben a fejezetben az kerül bemutatásra, hogyan lehet manuális módon telepíteni a MySQL adatbázis kezelőt egy számítógépre. Természetesen csomagból is telepíthető a rendszer de így talán jobb rálátásunk lesz a rendszerre. A programok lefordításához a következő csomagokra lesz szükség: 51

52 gcc g++ libncurses5 makefile Innentől kezdve feltételezzük, hogy ezek a programok fel vannak telepítve a Linux-ra és működőképesek. Ezután töltsük le például a mysql tar.gz állományt valamelyik tükör oldalról. A file egy tömörített tar archívum, így csomagoljuk ki: $ tar zxvf mysql tar.gz Ezután következik a program fordítása a szokásos módon: $ cd mysql $./configure --prefix=/opt/mysql --sysconfdir=/opt/etc --localstatedir=/opt/var/mysql --with-unix-socket-path=/opt/tmp/mysql.sock $ make $ make install Az első sorban belépünk a forrást tartalmazó könyvtárba, majd a második sorban konfiguráljuk. A configure shell script a szabad forrású programoknál szokásos használni és lényegében ez a script ellenőrzi, hogy a rendszeren a szükséges könyvtárak, fejléc file-ok, programok jelen vannak-e. A --prefix opcióval azt adjuk meg, hogy az installálás során melyik könyvtárba másoljuk a file-okat. Itt most kifejezetten egy olyan útvonalat adtunk meg (/opt/mysql) ami nem szokványos. Általában a /usr könyvtár alá installálódik a MySQL rendszer. A MySQL rendszer konfigurációs file-ja az /etc/mysql könyvtárba kerül alap esetben, de a --sysconfdir kapcsolóval egy másik könyvtárat adhatunk meg. A --localstatedir kapcsoló az adatbázis helyét adja meg (ha nem az alap könyvtárat akarjuk használni) és a --with-unix-socket-path kapcsoló pedig, hogy melyik filet használja majd a MySQL mint socket file. Alap esetben a socket file a /var/run/mysqld/mysqld.sock. Ezután hozzunk létre egy csoportot és egy felhasználót, akihez a MySQL rendszer tartozni fog: $ groupadd mysql $ useradd -g mysql mysql Biztosítani kell, hogy bizonyos file-ok is a felhasználó tulajdonába kerüljenek: $ chown -R mysql:mysql /opt/var/mysql A bináris, futtatható programok könyvtárát érdemes hozzáadni az elérési úthoz: $ export PATH=$PATH:/opt/mysql/bin Egy alap adatbázist is létre kell hozni: $ mysql_install_db --user=mysql A fenti parancs azt adja meg, hogy a mysql felhasználó végezze a műveleteket. A parancs létrehozza a szükséges alap adatbázist. Ezt majd egy kicsit később nézzük meg. Konfigurációs file-t is létre kell hozni, hogy a daemon majd tudja, mit hol talál. A konfigurációs helye az /opt/etc/my.cnf. Egy ilyen file-t létre is hozhatunk vagy egy mintát is bemásolhatunk a tar file-ból: 52

53 $ mkdir -p /opt/etc $ cd upport-files $ cp mysql /support-files/my-medium.cnf /opt/etc/my.cnf A fenti példához kapcsolódó konfigurációs file néhány fontosabb sora a következő lehet: [client] port = 3306 socket = /opt/tmp/mysql.sock [mysqld] port = 3306 socket = /opt/tmp/mysql.sock basedir = /usr/mysql datadir = /usr/mysql/data ledir = /usr/mysql/bin A konfigurációs file szekciókból áll. Egy szekciót a szögletes zárójelbe zárt szöveg vezet be, ami megmondja milyen programra vonatkoznak a beállítások. A client rész az adatbázishoz kapcsolódó kliens programokra vonatkozik, például a mysql programra. A socket paraméter adja, meg hogy a kliens hol találja meg a socket-et amin keresztül kapcsolódni tud az adatbázis szerverhez. A port opció adja meg, hogy a MySQL daemon milyen port-hoz kapcsolódjon és azon keresztül fogadja a kéréseket. A MySQL daemon indítása: /opt/mysql/bin/mysqld_safe --user=mysql & 8.6 Installálás csomagból $ apt-get install mysql-client $ apt-get install mysql-server 8.7 Beállítások Azért, hogy növeljük a biztonságot jelszót kell megadni a root felhasználónak. Ezt a jelszót nem a bejelentkezés (login) során, hanem az adatbázishoz való hozzáférés során kell megadni! /opt/mysql/bin/mysqladmin -u root password a-jelszo ahol a a-jelszo a konkrét jelszó. Ezután root felhasználó is csak jelszóval tud hozzáférni az adatbázishoz. Például a mysql kliens használata esetén: $ mysql -u root -p opciókat kell megadni, ahol a -u opció után a felhasználó nevet kell megadni és a -p opció azt jelenti, hogy a kliens jelszót fog kérni a felhasználótól. A fenti mysqladmin parancsot SQL parancsokkal is helyettesíthetjük: mysql> USE mysql; mysql> UPDATE user SET Password=PASSWORD( a-jelszo ) WHERE user= root ; mysql> FLUSH PRIVILEGES; 53

54 8.8 Adatbázisok kezelése Ez a fejezet több lépésben mutatja be, hogy hogyan lehet használni a MySQL adatbázist parancssorból. Lépjünk kapcsolatba az adatbázis szerverrel a kliens segítségével: $ mysql -u root -p Nézzük meg a MySQL szerveren tárolt adatbázisok listáját: mysql> show databases; Database information_schema mysql test Fontos, hogy a parancsok végére egy pontosvessző ( ; ) kerüljön! Hozzunk létre egy új adatbázist: mysql> create database proba; Query OK, 1 row affected (0.00 sec) majd nézzük meg ismét az adatbázisok listáját: mysql> show databases; Database information_schema mysql test proba Ezután jelöljük ki, hogy az új ( proba ) adatbázist használjuk, majd adjunk hozzá egy táblát: mysql> use proba; mysql> create table dolgozok (Nev char(20), Osztaly char(20), Munka char(20)); Query OK, 0 rows affected (0.01 sec) A létrehozott tábla megtekintéséhez a következő parancsot lehet kiadni: mysql> show tables; Tables_in_proba dolgozok illetve ha a tábla tartalmát akarjuk megnézni: mysql> describe dolgozok;

55 Field Type Null Key Default Extra Nev char(20) YES NULL Osztaly char(20) YES NULL Munka char(20) YES NULL rows in set (0.03 sec) A tabla szerkezetenek kiiratását másképpen is megadhatjuk: mysql> show columns from dolgozok; A táblában létrehozott oszlopok típusa (char(20)) egy szöveg. Más típust is meg lehet adni: char(m) : Fix hosszúságú karaktersorozat, ahol M értéke 1 és 255 között lehet VARCHAR(M) : Változó hosszúságú karaktersorozat INT : Egész szám. Az értelmezése tartomány: [ ] ha előjel nélküli számról van szó és [ ] ha előjeles a szám. FLOAT(m,n) : Valós szám, mely m számjegyből áll amiből n darab számjegy a tört rész. Például: FLOAT(4,2) esetén egy szám tárolt formája: További lehetséges adattípusok: DATE, TEXT, BLOB és így tovább. Elemek beszúrása egy táblába SQL paranccsal történik, például a következő módon: mysql> INSERT INTO dolgozok VALUES ( Joe Black, Adossag, Adoszedo ); mysql> INSERT INTO dolgozok VALUES ( Kovacs Istvan, Marketing, Bokszolo ); mysql> INSERT into dolgozok values ( Isaac Asimov, Marketing, Iro ); Kilépni a MySQL kliensből a következő paranccsal lehet: mysql> quit Bye További SQL minta példákat a MySQL kézikönyv is tartalmaz! 8.9 Biztonsági kérdések Kezdeti konfigurálás A MySQL rendszer installálása során egy példa adatbázis is installálásra kerül. Egy céges szerveren erre nincs szükség. Ugyanígy nincs szükség arra, hogy alap esetben a root-on kívül más is hozzáférjen az adatbázishoz. Ráadásul a root is csak a lokális gépről férjen hozzá a rendszerhez. Ennek eléréséhez a következő parancsokat adhatjuk ki: mysql> drop database test; mysql> use mysql; mysql> delete from db; mysql> delete from user where not (host="localhost" and user="root"); mysql> flush privileges; 55

56 8.9.2 Új felhasználó hozzáadása egyszerűen Új felhasználót is hozzáadhatunk a MySQL adatbázis kezelő rendszerhez. Ebben az esetben ezt a felhasználót használhatjuk arra, hogy bizonyos adatbázisokhoz, esetleg táblákhoz hozzáférjen. mysql> USE mysql; mysql> INSERT INTO user (Host, User, Password, Select_priv) -> VALUES (, web-user, password( supertitkos ), Y ); mysql> FLUSH PRIVILEGES; mysql> GRANT ALL PRIVILEGES ON proba.* TO web-user; mysql> FLUSH PRIVILEGES; A fenti parancs sorozatban a FLUSH PRIVILEGES; parancsok nagyon fontosak, mivel ezek biztosítja, hogy a GRANT táblák valóban frissítve legyenek. A fenti szintakszisra részletesebb magyarázat a következő fejezetekben található Hozzáférés kontroll A MySQL adatbáziskezelőben a biztonságot és az adatbázisokhoz való hozzáférést ACL-ek (Access Controll List) segítségével lehet kezelni. Nagyon fontos: A root felhasználó kivételével senkinek ne legyen joga a mysql adatbázisban a user táblához! Ugyanennyire fontos, hogy értsük meg a MySQL kontroll mechanizmusát és esetleg a GRANT és REVOKE parancsok használatát. A MySQL rendszerben 5 tábla játszik fontos szerepet a hozzáférés ellenőrzésben: user db host tables_priv columns_priv Amikor egy felhasználó csatlakozni szeretne egy adatbázishoz egy adott számítógépről akkor a MySQL először a user táblát ellenőrzi, hogy a felhasználó létezik a táblában, a táblában tárolt jelszó egyezik-e a megadott jelszóval és az adott számítógépről csatlakozhat-e a felhasználó. Így nézzük meg a user tábla szerkezetét: Field Type Null Key Default Extra Host char(60) PRI User char(16) PRI Password char(16) Select_priv enum( N, Y ) N Insert_priv enum( N, Y ) N Update_priv enum( N, Y ) N Delete_priv enum( N, Y ) N Create_priv enum( N, Y ) N Drop_priv enum( N, Y ) N Reload_priv enum( N, Y ) N Shutdown_priv enum( N, Y ) N Process_priv enum( N, Y ) N File_priv enum( N, Y ) N Grant_priv enum( N, Y ) N References_priv enum( N, Y ) N Index_priv enum( N, Y ) N 56

57 Alter_priv enum( N, Y ) N A táblából a Host, User és Password mezőket használja a rendszer a kezdeti kapcsolódásnál. Például: Host User Password valami.domain.com john bejegyzés esetén a john felhasználó, jelszó nélkül (NULL) csatlakozhat az adatbázishoz a valami.domain.com számítógépről. Nem csak számítógép név, hanem domain is megadható. Ráadásul itt is lehet wildcard karaktert használni, ami a százalék karakter ( % ). A karakter helyébe bármi behelyettesíthető, például: Host User Password % john ebben az esetben a john felhasználó bármelyik számítógépről csatlakozhat az adatbázishoz! Természetesen többféleképpen is használható a wildcard karakter, például: Host User Password %.domain.com john ebben az esetben a john felhasználó bármelyik számítógépről csatlakozhat a domain.com-ból az adatbázishoz. A számítógép vagy domain neve teljes nevvél és IP számmal is megadható. Nézzünk néhány példát: Teljes név vagy IP cím: vagy Név wildcard karakterrel: %.pmmf.hu. A wildcard karakter bárhol szerepelhet, így a jelentheti a vagy akár a címet. IP cím wildcard karakterrel: %. Ez utóbbi egyenértékű a következővel: / Azt is fontos észrevenni, hogy egy felhasználóra vonatkozóan több sor is lehet a user táblában. A sorokban a Host mező és esetleg a Password mező is különböző lehet így biztosítva pontos kontroll a hozzáférésben. Például nem kell engedélyezni a hozzáférést akárhonnan, ha esetleg két különböző domain-ből akarjuk elérni az adatbázis szervert. Ebben az esetben két sort szúrunk be a user adatbázisba. Ráadásul ezzel azt is biztosítani tudjuk, hogy a jelszó különböző legyen. Ezek után azt is fontos tudni, hogy a táblában milyen sorrendbe kerülnek a sorok. Például: 57

58 Host User %.domain.com john host.domain.com bár ez a tábla kinézete, de a MySQL ezt rendezni fogja olyan módon, hogy a specifikus gép nevek kerülnek előre és így ez lesz a memóriabeli kinézete: Host User host.domain.com %.domain.com john Ez azt jelenti, hogy ha a john felhasználó a host.domain.com gépről csatlakozik a szerverhez, akkor az első sor szerint történik a csatlakozás. Ez azért probléma, mert bár a john felhasználó nevet megadtuk, de mégis anonymous-ként fog csatlakozni a szerverhez, mivel az első illeszkedést használja a szerver. Ha sikerül a kapcsolódás, de a későbbi műveleteknél nincsennek meg a szükséges privilégiumaink, akkor valószínűleg nem a várt felhasználóként jelentkeztünk be. Ennek ellenőrzésére a CURRENT_USER() függvényt érdemes használni, például: mysql> SELECT CURRENT_USER(); CURRENT_USER() Ez azt jelenti, hogy felhasználói név nélkül jelentkeztünk be a lokális gépről. A CURRENT_USER() függvény formátuma mindig: felhasznalo@host A fejezetben bemutatott lépésekhez hasonlóan például töröljük azokat a sorokat, amelyek problémásak lehetnek a biztonság szempontjából, így a felhasználó nélküli sorokat: mysql> USE mysql; mysql> DELETE from user where User= Miután a kapcsolat létrejött minden további kérés esetén - SELECT, DELETE, UPDATE és így tovább - ellenőrzést végez a rendszer, hogy van-e az adott műveletre jogosultság. Előfordulhat, hogy bizonyos felhasználók csak a SELECT műveletet hajthatják végre, mások pedig módosíthatnak adatot is. Az alábbi lista tartalmazza a lehetséges privilégiumokat: Select_priv : a SELECT SQL művelet engedélyezett Insert_priv : az INSERT SQL művelet engedélyezett Update_priv : az UPDATE SQL művelet engedélyezett Delete_priv : a DELETE SQL művelet engedélyezett Create_priv : a CREATE SQL művelet engedélyezett, adatbázisok és táblák létrehozása engedélyezett 58

59 Drop_priv : a DROP művelet engedélyezett adatbázis és táblák esetén is Reload_priv : a MySQL szerver frissítése (refresh) és újratöltése (reload) engedélyezett Shutdown_priv : egy futó MySQL szerver leállítása engedélyezett Process_priv : a MySQL szerver aktivitásának követése engedélyezett File_priv : file-ok olvasása és írása engedélyezett a szerveren Grant_priv : a GRANT paranccsal más felhasználók privilégiumait állíthatja a felhasználó Index_priv : index létrehozás, szerkesztés és törlés engedélyezett Alter_priv : az ALTER SQL művelet engedélyezett Ezek között a privilégiumok között vannak kevésbé érzékenyek és veszélyesek is, hiszen egy lekérdezés kevésbé veszélyes mint hogy az adatokat módosíthatja valaki. (Persze a lekérdezés is lehet veszélyes, ha az adatok titkosak.) A Grant_priv privilégiumot csak nagyon ritkán kell engedélyezni, mivel ezzel egy felhasználó más felhasználók jogait változtathatja meg, növelheti. Érdekes figyelembe venni, hogy a File_priv privilégium nagyon veszélyes lehet és ezért szintén nem szabad gyakran használni. Itt az a probléma, hogy ezen privilégium birtokában bármilyen file-t elolvashat a felhasználó. Legalább is azokat a file-okat amikhez a MySQL szerver daemon-nak jogosultsága van. Ha a daemon root-ként fut, akkor minden file olvasható lesz az adott felhasználónak. Fontos megjegyezni, hogy ezek a privilégiumok a user táblában globálisan minden adatbázisra és táblára vonatkoznak! Ezért általában a legtöbb adminisztrátor ebben a táblában minden privilégiumot N -re állít és a finom hangolást a host és db táblákban végzik el. Nézzük a db tábla szerkezetét: Field Type Null Key Default Extra Host char(60) PRI Db char(32) PRI User char(16) PRI Select_priv enum( N, Y ) N Insert_priv enum( N, Y ) N Update_priv enum( N, Y ) N Delete_priv enum( N, Y ) N Create_priv enum( N, Y ) N Drop_priv enum( N, Y ) N Grant_priv enum( N, Y ) N References_priv enum( N, Y ) N Index_priv enum( N, Y ) N Alter_priv enum( N, Y ) N Itt is az első három mező kontrollálja az adott adatbázishoz való hozzáférést, az adatbázis nevét, a felhasználót, és az engedélyezett számítógépek nevét. Például: Host User Db all_privileges % test Y esetén minden felhasználó, bármely számítógépről kapcsolódhat a test adatbázishoz. Ha a Host bejegyzés üres a db táblában, akkor az engedélyezett számítógépeket a host táblából állapítja meg a rendszer: 59

60 Field Type Null Key Default Extra Host char(60) PRI Db char(32) PRI Select_priv enum( N, Y ) N Insert_priv enum( N, Y ) N Update_priv enum( N, Y ) N Delete_priv enum( N, Y ) N Create_priv enum( N, Y ) N Drop_priv enum( N, Y ) N Grant_priv enum( N, Y ) N References_priv enum( N, Y ) N Index_priv enum( N, Y ) N Alter_priv enum( N, Y ) N Ez a tábla is tartalmaz privilégiumokat, mivel ezeken karesztül azt tudjuk kontrollálni, hogy egy adott számítógépről történő kapcsolat esetén, mi engedélyezett. Nézzünk egy példát: mysql> SELECT Host, User, Password FROM user; Host User Password jim h35472k mysql> SELECT Host, User, Db FROM db Host User Db jim title mysql> SELECT Host, Db, Select_priv, Insert_priv FROM host Host Db Select_priv Insert_priv valami1.proba.com title Y Y valami2.proba.net title Y N tuzfall.proba.org title Y Y Ebben az esetben a jim nevű felhasználó csatlakozhat a title adatbázishoz minden olyan számítógépről, ami fel van sorolva a host táblában. A privilégiumoknak van egy harmadik szintjük is. Az első ellenőrzés a user tábla alapján történik. Ha ez nem ad megfelelő jogosultságot, akkor a db és host táblákat ellenőrzi a rendszer. Végül a tables_priv és columns_priv táblákkal akár adott táblák adott oszlopaihoz való hozzáférést lehet kontrollálni. Az egyes táblák szerkezete: tables_priv: Field Type 60

61 Host char(60) Db char(60) User char(16) Table_name char(60) Grantor char(77) Timestamp timestamp(14) Table_priv set( Select, Insert...) Column_priv set( Select, Insert...) columns_priv: Field Type Host char(60) Db char(60) User char(16) Table_name char(60) Column_name char(60) Timestamp timestamp(14) Column_priv set( Select, Insert, Update, References ) Új felhasználó hozzáadása ismét Most hogy már értjük a hozzáférés mechanizmust MySQL alatt nézzük meg újra a új felhasználók hozzáadását a MySQL rendszerhez. Két lehetőségünk is van. Használhatunk egyszerű SQL parancsokat: INSERT, UPDATE és DELETE, vagy használhatjuk a GRANT és REVOKE parancs párost. A különbséget a következő példával lehetne bemutatni: mysql> INSERT INTO user (Host, User, Password) -> VALUES( localhost, tom,password( tommygun )); mysql> INSERT INTO db (Host, Db, User, Select_priv, Insert_priv, -> Update_priv, Delete_priv, Create_priv, Drop_priv) VALUES -> ( localhost, recipes, tom, Y, Y, Y, Y, N, N ); aminek megfelel a következő GRANT parancs: mysql> GRANT SELECT, INSERT, UPDATE, DELETE, ON recipes.* TO tom@localhost -> IDENTIFIED BY tommygun ; Itt fontos megjegyezni, hogy a GRANT és REVOKE parancsok hatására a jogosultságok azonnal aktiválódnak, míg a hagyományos SQL parancsok esetén újra kell tölteni (reload) a szervert. Az újratöltést kétféleképpen hajthatjuk végre, a shell-ben: $ mysqladmin reload vagy a mysql kliensben: mysql> FLUSH PRIVILEGES; GRANT parancs Az aktuális privilégiumok kiiratására a következő parancs használható: 61

62 $ SHOW GRANTS;... GRANT ALL PRIVILEGES ON *.* TO localhost IDENTIFIED BY PASSWORD... WITH GRANT OPTION A GRANT parancs szintakszisa: mysql>grant priv_type [(column_list)] [, priv_type [(column_list)]...] ON {tbl_name * *.* db_name.*} TO user_name [IDENTIFIED BY password ] [, user_name [IDENTIFIED BY password ]...] [WITH GRANT OPTION] Lehetséges privilégiumok (priv_type): ALL PRIVILEGES : Szinte minden jogosultságot megad, kivéve a veszélyesebbeket: FILE, PROCESS, RELOAD, SHUTDOWN. Ezeket explicit módon meg kell adni a felhasználónak. ALTER : Jogosultságot ad a táblák szerkezetének megváltoztatására, de csak addig amíg az nem érinti az indexeket. Lényegében az ALTER SQL parancs végrehajtása engedélyezett ezzel a privilégiummal. CREATE : Ez a jogosultság engedélyezi új adatbázisok és táblák létrehozását amíg az nem érinti az indexeket. Lényegében a CREATE SQL parancs végrehajtása engedélyezett ezzel a privilégiummal. DELETE : Ez a jogosultság engedélyezi sorok törlését táblákból, de nem engedi adatbázisok törlésée. DROP : Ez a jogosultság engedélyezi adatbázisok törlését, de indexeket nem. FILE : Ez a jogosultság engedélyezi, hogy a számítógépen file-okhoz férjen hozzá az adott felhasználó. INDEX : Ez a jogosultság engedélyezi, hogy a felhasználó indexeket kezeljen, létrehozzon, töröljön, stb. INSERT : Ez a jogosultság engedélyezi új sorok beillesztését táblákba. Lényegében az INSERT SQL parancs végrehajtása engedélyezett ezzel a privilégiummal. PROCESS : Jogosultságot ad a MySQL szálakhoz, beleértve azok leállítását. Például végrehajthatjuk a SHOW PROCESSLIST vagy KILL SQL parancsokat. REFERENCES : Ennek nincs jelentősége MySQL alatt, csak az Oracle adatbáziskezelővel való kompatibilitás miatt létezik. RELOAD : Engedélyezi a felhasználónak, hogy a cache-ben tárolt adatokat újraolvastassa az adatbázisból. SELECT : A SELECT SQL parancs végrehajtása engedélyezett ezzel a privilégiummal. SHUTDOWN : Engedélyezi a felhasználónak az adatbáziskezelő leállítását. UPDATE : Az UPDATE SQL parancs végrehajtása engedélyezett ezzel a privilégiummal. Ugyanakkor a felhasználó nem adhat hozzá és nem törölhet adatot. USAGE : A felhasználó csak bejelentkezhet a MySQL szerverre de semmi mást nem csinálhat. A parancs megértésének egyik legjobb módszere a példák használata: 62

63 mysql>grant usage ON *.* TO ->IDENTIFIED BY ilovewidgets ; Ez a widgetadmin-nak biztosítja, hogy a localhost-ról, magáról az adatbázis szerverről, kapcsolódjon az adatbázishoz és a jelszó a ilovewidgets lesz. Ez az utasítás csak a kapcsolódást (usage) teszi lehetőve, semmi mást. Ugyanakkor minden adatbázis minden táblájához kapcsolódhat: *.* Ezután ha azt szeretnénk, hogy ez a felhasználó a widgets adatbázis minden táblájához hozzáférjen és végrehajthasson SELECT, INSERT, UPDATE és DELETE műveleteket, akkor a következő utasítást kell kiadni: mysql>grant SELECT, INSERT, UPDATE, DELETE ->ON widgets.* TO widgetadmin@localhost; REVOKE parancs A jogosultságok visszavonására alkalmas parancs, a REVOKE szintakszisa: REVOKE priv_type [(column_list)] [, priv_type [(column_list)]...] ON {tbl_name * *.* db_name.*} FROM user_name [, user_name...] Egy dolgot azért érdemes fejben tartani, hogy bár a REVOKE parancs minden privilégiumot képes elvenni a felhasználótól, de magát a felhasználót nem törli a MySQL adatbázis rendszerből: mysql>revoke ALL PRIVILEGES ON widgets.* ->FROM widgetadmin@localhost; A felhasználót explicit módon kell törölni: mysql>delete FROM user WHERE user = widgetadmin ; Query OK, 1 row affected (0.00 sec) mysql>flush privileges; Felhasználó által szolgáltatott adatok Soha ne bízzunk a felhasználótól származó adatokban! Például tegyük fel, hogy egy Web formon keresztül egy azonosítót adhat meg a felhasználó, amit a program beilleszt egy SQL lekérdezésbe: SELECT * FROM tblname WHERE ID=456 A fenti példában az azonosító a 456 volt. Ez teljesen jól működik, de mi van ha a felhasználó a következőt gépelte be: 456 OR 1=1 Ez a kifejezés megváltoztatja a lekérdezést: SELECT * FROM tblname WHERE ID=456 OR 1=1 Mivel az 1=1 mindig igaz lesz és a két feltétel között vagy kapcsolat van ezért ez a kifejezés a teljes táblát lekérdezi. Ez nem csak adatvédelmi problémákat vet fel, hiszen így minden adat látható lesz, hanem egy ilyen lekérdezés DOS (Denial-Of-Service) támadásnak is megfelel, vagyis túl sokszor végrehajtva lassíthatja a szervert. A fenti problémára az egyik megoldás, hogy idézőjelet teszünk a paraméter köré: 63

64 SELECT * FROM tblname WHERE ID= 456 mert ebben az esetben a begépelt paraméter a szöveg része lesz és nem pedig a kifejezés része: SELECT * FROM tblname WHERE ID= 456 OR 1= Hálózati védelem A MySQL adatbáziskezelő alap esetben a 3306-os porthoz kapcsolódik, ezért mindenképpen érdemes ezt a portot védeni a megfelelő tűzfal beállításokkal!!! Például ellenőrizhetjük, hogy a porthoz lehet-e kapcsolódni: $ telnet gep-neve 3306 Ha visszakapunk valamilyen karaktersorozatot, akkor kapcsolódni lehet a porthoz root jelszó helyreállítása $ /etc/init.d/mysql stop $ mysqld_safe --skip-grant-tables --skip-networking & $ mysqladmin -u root password uj-jelszo $ kill %1 $ /etc/init.d/mysql start A fenti parancsok a --skip-grant-tables opcióval biztosítjuk, hogy az adatbázis szerver ne vegye figyelembe az adatbázisban tárolt jogosultságokat. A --skip-networking opció pedig nem hálózatos módban indítja el a szervert, hiszen jogosultság kezelés nélkül a hálózaton az adatbázisunk nagy veszélyben lenne Néhány biztonsági kérdés összefoglalása A MySQL szerver daemon-t mindig mysql felhasználóként futtassuk és ne root vagy nobody felhasználóként. A MySQL adatbázisokat tartalmazó könyvtár jogai legyenek: drwx és a tulajdonosa a mysql felhasználó legyen. Ha lehet kerüljük a wildcard karakter használatát a számítógép nevekben. Amennyire csak lehet, használjunk specifikus és pontos gép neveket. Grant_priv és File_priv privilégiumokat csak a root felhasználó birtokoljon. A MySQL kliens indításánál figyeljünk arra, hogy a jelszót ne a parancssorban adjuk meg. A rossz megoldas: $ mysql -u root -p valami Ezzel az a probléma, hogy ebben az esetben a jelszó a parancssor része és látható például a ps parancs számára vagy bekerül a.bash_history file-ba. A helyes indítás: 64

65 $ mysql -u root -p A felhasználókat igyekezzünk korlátozni egy-egy adatbázisra vagy táblára. Végül csak a root felhasználó tudja olvasni és módosítani az hozzáférés kontrollra használt táblákat Adatbázis mentés és visszaállítás Fontos lehet az adatbázisban tárolt adatok elmentése időszakonként (backup) és azok visszaállítása. Több módszer is létezik, ezekből tárgyalunk itt néhányat mysqldump program Ez az egyik legkényelmesebb módszer, bár valószínűleg nem a legjobb. A program el tud menteni egy, vagy több adatbázist, illetve akár specifikusan egy-egy táblát. Nézzünk néhány variációt: Egy adatbázis elmentése: $ mysqldump [options] db_name Egy adatbázis több táblájának elmentése: $ mysqldump [options] db_name tabla1 tabla2 tabla3... Több adatbázis elmentése: $ mysqldump [options] --databases [options] db_name1 db_name2... Az összes adatbázis elmentése: $ mysqldump [options] --all-databases [options] Az options opciók teljes listáját a --help kapcsoló segítségével lehet kilistázni, de nézzünk meg két nagyon fontos opciót: --no-create-info : Ezt a kapcsolót akkor használjuk ha csak az adatbázis adatait akarjuk elmenteni, de az adatbázis szerkezetét nem. Vagyis olyan információra nincs szükség, amivel a táblákat létre lehetne hozni. --no-data : Az előző opció fordítottja, hogy csak az adatbázis szerkezetét akarjuk elmenteni, vagyos hogy hogyan kell az adattáblákat létrehozni és magát az adatokat nem akarjuk elmenteni. Például: $ mysqldump -u root -p --no-create-info widgets > widgets-backup.sql vagy $ mysqldump -u root -p --no-data widgets > widgets-backup.sql Ha az adatokat azért akarjuk elmenteni, hogy egy másik MySQL adatbázisba beimportáljuk, akkor érdemes a --opt kapcsolót használni, ami optimalizált módon írja ki az adatokat és így gyorsabban lehet majd az adatokat visszaolvasni: $ mysqldump -u root -p --opt widgets > widgets-backup.sql 65

66 Adatbázis visszaállítás Az adatbázis visszaállítására a mysql kliens használható: $ mysql -u user-id -p < backup.sql 8.11 Loggolás A MySQL adatbáziskezelő rendszer az eseményeket, különböző file-ba rögzíti, tárolja, loggolja: error : Az elindított mysqld_safe daemon szabványos hiba kimenete ebbe a file-ba kerül. A file neve mindig a gép neve és az err kiterjesztés, pédlául: hostnev.err. A file szintén tartalmaz bejegyzéseket minden daemon indításról és leállításról. bináris log : A bináris log minden olyan SQL parancsot tárol, amelyik adatot frissít vagy megváltoztat. (Ha egy törlő parancs nem változtat meg semmit, akkor nem kerül be ebbe a file-ba.) A parancsokat a végrehajtás sorrendjében térolja. A bináris log file jól használható, mint egy biztonsági mentés. Például ha minden nap elmentjük az adatbázisunkat és valamelyik nap közben megsérül az adatbázis, akkor csak helyre kell állítani az előző napi állapotot, majd az aznapi bináris log-ban található műveleteket végrehajtani és megkapjuk az utolsó jó állapotát az adatbázisnak. Ha a szervert a --log-bin=file opcióval indítjuk el, akkor a file-ba írja az eseményeket a rendszer. Valójában nem csak egy file-t használ az adatbáziskezelő rendszer hanem a file végéhez egy számot illesztve többet is, például: file.1 file.2 és így tovább. Azért kell több file, mert például ha túl nagy lenne a file mérete akkor egy újabbat kell kezdeni. Az adatbáziskezelő ezen kívül létrehoz egy index file-t ami az összes bináris log file nevét tartalmazza. Az index file helyét az --log-bin-index=file opció adja meg. Például: $ ls -l /opt/var/mysql... -rw-rw mysql mysql -rw-rw mysql mysql -rw-rw mysql mysql -rw-rw mysql mysql -rw-rw mysql mysql :20 mysql-bin :20 mysql-bin :20 mysql-bin :20 mysql-bin :20 mysql-bin.index A bináris log file-okat a mysqlbinlog paranccsal lehet megnézni, például: $ mysqlbinlog mysql-bin # at 4 # :06:00 server id 1 Start: binlog v 1, server log created :06:00 Illesszünk be adatot: $ mysql mysql> USE test; mysql> INSERT INTO test ( object_id, object_title ) VALUES (1, test ); Query OK, 1 row affected (0.02 sec) mysql> QUIT; 66

67 Bye $ és nézzük meg a bináris log file-t $ mysqlbinlog mysql-bin # at 4 # :06:00 server id 1 Start: binlog v 1, server log created :06:00 # :39:38 server id 1 Query thread_id=2 exec_time=0 error_code=0 USE test; SET TIMESTAMP= ; INSERT INTO test ( object_id, object_title ) VALUES (1, test ); $ Ha új log file-t akarunk kezdeni, akkor a következő parancsot használhatjuk: $ mysqladmin -u root -p flush-logs Ha a bináris logból akarjuk újra létrehozni az adatbázist, akkor a kliensnek át kell adni a file tartalmát: $ mysqlbinlog mysql-bin mysql lassú lekérdezés log : (slow query log) Ez a file azokat az SQL parancsokat tartalmazza amelyek tovább tartanak mint a long_query_time paraméter által megadott idő. Ez a log hasznos lehet arra, hogy azonosítsuk az adatbázis azon részeit amelyek a lassú végrehajtást okozzák és amelyeket tuningolni kellene. A log file létrehozását a --log-slow-queries=file opcióval lehet megadni Replikáció 8.13 Kluszterezés 8.14 Adatbázis optimalizálás 67

68 68

69 9. Fejezet Apache web szerver 9.1 Bevezetés és alapok Mit csinál a web szerver? A web szerverek lényege, hogy egy URL-t filenévre transzformáljuk, majd a file tartalmát visszaküldjük a kliensnek az Interneten. Az URL-ből nem csak file név lehet, hanem egy program neve is, ami majd generálja azt az adatot, amit visszaküld a szerver a kliensnek. Az URL jelentése: Uniform Resource Locator és három részből áll: <séma>://<host>/<útvonal> A web oldalak esetén a séma a http. A HTTP jelentés: Hypertext Transfer Protocol. A host a gép neve, például: de lehet IP cím is. Az path pedig az elérési út a file-hoz vagy könyvtárhoz. Alap esetben ez csak a főkönyvtár: / Mit csinál a web kliens? A web kliensnek egyszerű dolga van, mert csak azt kell elküldenie, hogy melyik file-t, tartalmat akarja lekérdezni. Ennek formátuma: Az RFC 1738-as dokumentum szerint ebből több rész is elhagyható. Általában csak a host-ot és a path-t szoktuk megadni, példuál: Amikor web kliens megkapja a címet, akkor első lépésben meghatározza, hogy a címnek milyen IP szám felel meg. (DNS-t használva.) Ezen az IP címen levő számítógépet szólítja meg a kliens. Mivel a cím nem tartalmaz portra vonatkozó adatot ezért az alap értéket használja a kliens, a 80-as portot. Ezután a kliens TCP kapcsolatot nyit és a következő üzenetet küldi: GET /vala/hol/index.html HTTP/1.0<CR><LF><CR><LF> A kérésre a web szerver elküldi a válasz tartalmat, majd lezárja a kapcsolatot. Próbáljuk ki: telnet 80 GET HTML/1.1 69

70 Trying Connected to Escape character is ˆ]. HTTP/ OK Date: Mon, 25 Feb :03:19 GMT Server: Apache/ (Unix) Cache-Control: max-age=86400 Expires: Tue, 26 Feb :03:19 GMT Accept-Ranges: bytes Content-Length: 4946 Content-Type: text/html <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" " <html> <head> <meta http-equiv="content-type" content="text/html; charset=iso " /> <title> Azért érdemess a telnet programot használni, mert a port szám is megadható. Ugyanakkor bizonyos telnet programok nem írják ki azt amit begépelünk, így erre figyeljünk. A GET sor begépelése után egy sor adatot fogunk kapni Miért az Apache? Manapság az Apache a legeltejedtebb web szerver az Interneten. A piaci részesedése legalább kétszer akkor mint az utána következő szoftveré. Ráadásul az Apache open-source software, vagyis a forrsákódot bárki megnézheti és saját igényei szerint módosíthatja. Az Apache nagyon sokféle igényt ki tud elégíteni. Alkalmas olyan web oldal megjelenítésére ami csak statikus részekből áll, de dinamikus tartalom is megjeleníthető Az Apache web szerver Az Apache Web szerver futtatható programja a httpd, ami általában a háttérben fut. Minden web szerver egy adott könyvtárból szolgálja ki a file-okat. A web szervernek általában négy fő könyvtára van: conf : A konfigurációs file-okat tartalmazó könyvtár. A file-okból a legfontosabb a httpd.conf file, ami A konfigurációs file. Például ez a file adja meg, hogy melyik könyvtárból szolgáljuk ki a web oldalakat. htdocs : Ez a könyvtár tartalmazza a HTML oldalakat. Természetesen a könyvtáron belül lehetnek alkönyvtárak is, amiben további HTML oldalak lehetnek. Mivel mindenki hozzáférhet ehhez részhez, így különösen figyelni kell erre a részre biztonsági szempontból. logs : A log file-okat tartalmazza. File-ban rögzítünk minden oldalhoz való hozzáférést. cgi-bin : A CGI szkripteket tartalmazza ez a könyvtár. A szkripteket a web szerver hajtja végre és az eredményt küldi vissza a kliensnek. Szintén különös odafigyelést igényel biztonsági szempontból. 70

71 9.2 Installálás Kétféle módon lehet az Apache web szervert felinstallálni. Az egyik a fél manuális a másik az egyszerűsített (Out of the box) módszer. Mind a két módszer során shell scriptek futnak le és Makefile-okat hoznak létre. Ezeket a Makefile-okat használja a make parancs, hogy lefordítsa a rendszert. 9.3 Egyszerűsített installálás forrásból Miután letöltöttük a forrás kódot és kitömörítettük egy könyvtárba, a program fordítása három sorban megoldható. Ugyanakkor fontos, hogy a fordítást root felhasználóként végezzük el, mivel ha egyszerű felhasználóként végezzük a számítást akkor a web szerver a 8080 porton fog kommunikálni. Ráadásul ebben az esetben a web szerver a 80-as port használatát kifejezetten nem engedi! A rendszer fordításához szükséges három sor: $./configure $ make $ make install Ha minden jól ment akkor a /usr/local/bin könyvtárban megtaláljuk a web szerver programot: httpd. Az installálás után megnézhetjük, hogy milyen könyvtárakba másoltunk, installáltunk file-okat a következő módon: $./configure --show-layout > elrendezes A lefordított modulok listáját a httpd -l paranccsal kaphatjuk meg. 9.4 Manuális installálás forrásból Először is olvassuk el a forrás könyvtárban a README file-t és és a src könyvtárban az INSTALL file-t. A két file tartalmazza a részletes instrukciókat a web szerver lefordításához. Következő lépés, hogy a src/configuration.tmpl file-t másoljuk át Configuration file-ba. Ezt a file-t kell szerkeszteni, hogy a fordításhoz mindent beállítsunk. A Configuration file-ban öt dolog található: 1. A megjegyzések a # karakterrel kezdődnek. 2. A szabályok, amik a Rule szóval kezdődnek. 3. A parancsok, amiket majd be kell illeszteni a Makefile file-ba. Ezek a sorok semmilyen speciális karakterrel nem kezdődnek. 4. Modul választás. Ezek a sorok a AddModule kulcsszóval kezdődnek és azt adják meg, hogy mely modulokat kell bekapcsolni és lefordítani. 5. Az opcionális modulok esetén a sor a %Module szóval kezdődik. Ezeket a modulokat le kell fordítani, de nem kell bekapcsolni, majd csak később Modulok kiválasztása A következő lista felsorol néhány az alap esetben bekapcsolt modulokból. Ezeket a sorokat ki kell kommentezni a Configuration file-ban. 71

72 AddModule modules/standard/mod env.o Ez a modul beállítja azokat a környezeti változókat amelyeket a CGI scripteknek ad át a rendszer. AddModule modules/standard/mod log config.o Ez a modul meghatározza és konfigurálja a loggolást. AddModule modules/standard/mod mime magic.o Ez a modul határozza meg a file-ok típusát. AddModule modules/standard/mod mime.o Ez a modul adja meg, hogy melyik file kiterjesztéshez milyen file tartalom tartozik. AddModule modules/standard/mod cgi.o Ez a modul hajtja végre a CGI scripteket. AddModule modules/standard/mod imap.o Ez a modul hajtja végre a kép térképeket (imagemap). AddModule modules/standard/mod alias.o Ez a modul biztosítja az URL fordítás és átirányítás lehetőségét. AddModule modules/standard/mod rewrite.o Ez a modul biztosítja az URL újraírást. AddModule modules/standard/mod access.o Ez a modul teszi lehetővé az egyes web oldalak hozzáférés védelmét. AddModule modules/standard/mod auth.o Ez a modul biztosítja az authentikáció lehetőségét. Később amikor a konfigurációs file-okat készítjük, figyelembe lehet venni, hogy az adott modul része-e a rendszernek, például:... <IfModule mod_log_config.c> LogFormat "host %h, user %u, time %t, request %r, status %s" </IfModule>... Ezek a konfigurációs file-ok így rendszerről rendszerre másolhatók, mivel a file figyelembe veszi a modul létezését vagy hiányát Egyéb beállítások Ha a fordítás során extra beállításokat szeretnénk tenni, vagy extra könyvtárat szeretnénk megadni, akkor a következő opciók használhatók a Configuration file-ban. EXTRA_CFLAGS= EXTRA_LDFLAGS= EXTRA_LIBS= EXTRA_INCLUDES= A Configuration file-ban néhány egzotikus beállítás is megadható szabályok (Rule) segítségével Fordítási folyamat A Configuration file beállításai után, root-ként a következő parancsot kell kiadni: $./Configure aminek hatására valami hasonlót fogunk kapni 72

73 Using config file: Configuration Creating Makefile + configured for FreeBSD platform + setting C compiler to gcc + Adding selected modules o status_module uses ConfigStart/End: o dbm_auth_module uses ConfigStart/End: o db_auth_module uses ConfigStart/End: o so_module uses ConfigStart/End: + doing sanity check on compiler and options Creating Makefile in support Creating Makefile in main Creating Makefile in ap Creating Makefile in regex Creating Makefile in os/unix Creating Makefile in modules/standard Creating Makefile in modules/proxy Ezután már le lehet fordítani a web szervert: $ make 9.5 Apache működtetésének alapjai Apache futtatása A web szervert akkor lehet futtatni, ha van site (web oldalak sorozata) amit meg lehet jeleníteni. Ha létrehozunk egy könyvtárat a site számára, akkor annak három alkönyvtárat kell tartalmaznia: conf, logs és htdocs. A conf konfigurációs könyvtárban három konfigurációs file is lehet: srm.conf, access.conf és httpd.conf. A beállítások maradhatnak ebben a három file-ban, de a jelenleg érvényes stratégia szerint a három file-t össze szokták fűzni egy file-ba: httpd.conf. Így könnyebb kezelni és biztonságosabb is. Még egy fontos megjegyzés! Az Apache szerver egy igen nagy és komplikált konfigurációs fileal érkezik. A kezdő felhasználóknak elég nehéz átlátni és megérteni az opciókat ebben a file-ban. Az új felhasználók általában azt szokták csinálni, hogy ezt a file-t módosítgatják. Később ezeket a módosításokat elfelejthetjük és az összetettség miatt nem is biztos, hogy ki lehet majd bogozni. Így ez egy nagyon rossz stratégia! A legjobb módszer az, hogy egy minimális konfigurációs file-al kezdjünk és csak azokat a beállításokat adjuk hozzá amikre feltétlenül szükség van. A web szerver elindításánál megadhatjuk, hogy melyik site-ot szolgálja ki a web szerver és melyik konfigurációs file-t használja: $ httpd -f /usr/local/conf/httpd.conf -d /usr/local/www/siteom Ha nem akarjuk mindig parancssorból indítani a web szervert, akkor írhatunk egy script-et is: % cat > /usr/local/bin/go test -d logs mkdir logs httpd -f pwd /conf/httpd.conf -d pwd ˆd Ez a script feltételezi, hogy a site fő könyvtárában futtatjuk le. 73

74 9.5.2 Apache leállítása A web szervert többféleképpen lehet leállítani. Az egyik lehetőség, hogy a futó processzusok közül kikeressük a web szerver processzusait és azokat állítjuk le: $ ps -fe grep httpd $ kill PID Linuxon a következő parancs is használható: $ killall httpd vagy a futó web szerver processz ID-jét egy file is tartalmazza, amit szintén felhasználhatunk a leállításra: $ kill cat /usr/localwww/siteom/logs/httpd.pid Végül az apachectl program is használható a web szerv elindítására vagy leállítására A szervert futtató felhasználó Fontos, hogy a web szert ne futtassuk root vagy nobody felhasználóként. Mind a két eset biztonsági rést jelent a rendszeren. 1 A legbiztonságosabb megoldás, hogy létrehozunk egy felhasználót és egy csoportot. A csoportnak csak ez a falhasználó legyen a tagja. Például: $ groupadd webuser $ useradd -g webuser webuser A felhasználót állítsuk úgy be, hogy senki ne tudjon ezzel az azonosítóval belépni. Például adjunk meg valami nagyon bonyolult és hosszú jelszót, vagy alkalmazzuk valamelyik módszert a 4. fejezetből. Ezen kívül a felhasználónak csak olyan file-okhoz legyen hozzáférési joga, amit elérhetővé akarunk tenni a külvilág felé. Az operációs rendszer után a web szervernek is meg kell mondani, hogy ez a felhasználó futtassa a web szervert. A httpd.conf konfigurációs file-ban a következőket kell beállítani: User webuser Group webgroup 9.6 Apache beállításai, konfigurációk Alap beállítások A httpd.conf konfigurációs file-ban további beállításokat lehet tenni: Meg kell adni a web szervert futtató gép nevét ServerName <yourmachinename> Meg kell adni annak a könyvtárnak a nevét is, ahol a site file-jai találhatók. Ezt az útvonalat fogja a web szerver minden kért file-hoz hozzáfűzni. 1 A +nobody+ felhasználóval például az a probléma, hogy más rendszer komponenseket is ezzel a felhasználóval futtatunk és ha azok egyikét valaki feltöri, akkor hozzáférése lesz a web szerverhez is. 74

75 DocumentRoot <path> A konfigurációs és log file-ok helyét a ServerRoot opcióval lehet megadni: ServerRoot <path> A hiba log file neve is külön megadható. Ez a file fogja tartalmazni a bejegyzéseket a különböző hibákról, például ha nem található egy web lap. ErrorLog <filename> A régebbi Apache szerverek esetén automatikusan jött létre az a log file, ami a lekért oldalakat, illetve a lekéréseket tartalmazza. Ez a file a log/access_log volt. Az újabb Apache szervereken (v2) ezt a log file-t explicit módon meg kell adni: TransferLog <filename> A futó web szerver processzusának azonosító számát (PID) a rendszer szintén egy file-ban tárolja. A file nevet a következőképpen lehet megadni: PidFile <filename> Az Apache v2 megköveteli azt is, hogy megadjuk, hogy a web szerver melyik porton várja a kéréseket. A host név is megadható ebben az esetben. Ez a preferált opció a BindAddress és Port opciókkal szemben. Listen <hostname:port> A régebbi web szervereken ha azt akartuk, hogy a web szerver ne minden IP címen végezzen kiszolgálást, hanem csak egy adott címen, akkor a BindAddress opciót kellett használni. Az Apache v2-ben a Listen opciót kell használni. A Port opció többféle helyzetben használható. Ha a <Virtualhost> opción kívül használjuk és a BindAddress illetve Listen opciók nincsennek megadva, akkor ennek a segítségével lehet megadni a portot, amin az Apache web szerver várja a kéréseket. Ha ezt az opciót a <Virtualhost>-on belül használjuk, akkor a web szerver ezt a portot fogja használni amikor a szerver saját maga számára generál URL-t. (Ez nem azt a portot adja meg, amelyiken a web szerver válaszol a kliensnek, mivel az a port a <Virtualhost>-on belül van definiálva.) Az alábbiakban egy példa konfigurációs file található: ServerName Listen 80 DocumentRoot /usr/local/www/site/htdocs ServerRoot /usr/local/www/site/ TransferLog /usr/local/www/site/logs/access.log ErrorLog /usr/local/www/site/logs/error.log PidFile /usr/local/www/site/logs/httpd.pid Blokk direktívák Az Apache web szervernek több olyan blokk direktívája van, amelyek a többi opció alkalmazását korlátozza például host-okra, könyvtárakra és file-okra. A blokk direktívák listája: <VirtualHost> 75

76 <Directory> <Files> <Location> A lista azt a sorrendet is mutatja, hogy milyen sorrendben írják felül és szűkítik az alkalmazásukat. Például a <Directory> blokkban megadott opciók könyvtárakra vonatkoznak, amiket felül írhatnak a <Files> blokkban megadott opciók, amiket felül írhatnak a <Location> blokkban megadott opciók. <Directory> blokk direktíva A <Directory> blokk direktíva könyvtárakra vagy könyvtárak csoportjaira vonatkozó opciókat tartalmaz. Szintakszisa: <Directory dir >... </Directory> Egy dolgot nagyon fontos megérteni, hogy a dir az abszolút útvonalra vonatkozik, így a <Directory \ > fejléc a főkönyvtárra vonatkozik és nem a DocumentRoot könyvtárra. A dir helyén wildcard karakter is szerepelhet:? egy karakterre illeszkedik, * bármilyen karaktersorozatra illeszkedik és a [ ] pedig karakter tartományra illeszkedik. Ha a dir előtt egy karakter szerepel akkor utána teljes reguláris kifejezés használható. A <Directory dir> jelentése megegyezik a <DirectoryMatch dir> kifejezéssel, így például az alábbi két kifejezés ugyanaz: <Directory [a-z].* > ami egyenlő ezzel: <DirectoryMatch [a-z].* > ami azt jelenti, hogy bármilyen karakterrel kezdődő könyvtár névre illeszkedik. <Files> blokk direktíva A <Files> file-okra vonatkozó opciókat fog össze. Szintakszisa: <Files file >... </Files> ahol viszont a file a DocumentRoot könyvtárhoz képesti relatív útvonalat, illetve file-t ad meg! It is igaz, hogy ha a karakter szerepel a Files után akkor utána teljes reguláris kifejezés használható. Ezen kívül ebben az esetben is használható a <FilesMatch> opció. Például a grafikus file-okra vonatkozó opciók: <FilesMatch "\.(gif jpeg png)$" > Ez az opció használható a.htaccess file-okon belül, míg a <Directory> és a <Location> nem. 76

77 <Location> blokk direktíva A <Location> URL-ekre vonatkozó opciókat fog össze. Szintakszisa: <Location URL >... </Location> <IfDefine> blokk direktíva Az a blokk direktíva bekapcsol bizonyos opciókat, amikor a web szervert a -D nev módon indítjuk el. Szintakszisa: <IfDefine nev>... </IfDefine> Ennek a direktívának a segítségével egy konfigurációs file-ban több konfiguráció is eltárolható. Például ez alkalmas tesztelési opciók megadására. <IfModule> blokk direktíva Ez a direktíva az általa befoglalt opciókat kapcsolja be, ha az adott modul elérhető a web szerverben. Szintakszisa: <IfModule [!]module-file-name>... </IfModule> A felkiálltójel tagadást jelent, vagyis arra az esetre vonatkozik ha a modul nincs betöltve További opciók ServerName Az opció segítségével megadható az a név, amit a web szerver visszaküld a kliensnek. Ha nem adnánk meg, akkor a web szerver megpróbálja kitalálni a nevet a gép IP címéből. Példa a használatra: ServerName Ha valaki a ez.pelda.hu oldalt kéri le, akkor a szerver a fenti opció kiadásával a nevet fogja visszaadni a kliensnek. 9.7 Virtuális host-ok Előfordulhat, hogy több web szervert szeretnénk üzemeltetni. Például új kutatócsoport jön létre az egyetemen, vagy egy cégnél a mérnökök mellett marketing osztály is létrejön. Két alapvető megoldás lehetséges: 1. Futtassunk egy web szervert, amely több virtuális oldalt szolgál ki. Ez a leggyakoribb megoldás. 2. Két web szervert futtatunk egy számítógépen és mindegyik egy site-ot szolgál ki. Ez a fejezet az első megoldással foglalkozik. 77

78 9.7.1 Név alapú virtuális host-ok Ebben az esetben a számítógépnek egy IP címe van, de erre az IP címre több név is regisztrálva van a DNS-ben. A kliensek ezek közül a nevek közül bármelyiket megszólíthatják és különböző web oldalra kerülnek. A legfontosabb dolog a következő opció megadása a konfigurációs file-ban: NameVirtualHost cim[:port] A cim egy IP cím, amihez egy port számot is megadhatunk opcionálisan. Ezt az opciót követi több <VirtualHost> szekció, amelyeken belül ServerName opciónak is szerepelnie kell. Bár úgy tűnik a ServerName opció azonosítja a host-ot, de valójában a <VirtualHost> utáni név azonosítja, a ServerName opció azt a nevet adja meg amit a web szerver visszaküld a kliensnek. Összefoglalva lényeget, ez a lehetőség az IP címet név alapján osztjuk fel. Nézzünk egy példát, ami egy konfigurációs file részlete: NameVirtualHost <VirtualHost ServerName ServerAdmin [email protected] DocumentRoot /usr/www/site.virtual/htdocs/vevok ErrorLog /usr/www/site.virtual/nev-alapu/logs/error_log TransferLog /usr/www/site.virtual/nev-alapu/logs/access_log </VirtualHost> <VirtualHost sales.pelda.com> ServerName sales.pelda.com ServerAdmin [email protected] DocumentRoot /usr/www/site.virtual/htdocs/salesmen ErrorLog /usr/www/site.virtual/nev-alapu/logs/error_log TransferLog /usr/www/site.virtual/nev-alapu/logs/access_log </VirtualHost> Fontos, hogy bár a web oldalakat különböző helyről szolgálja ki a web szerver a log-ok akár közös file-ba is kerülhetnek IP cím alapú virtuális host-ok Bár a jövőben valószínűleg a név alapú virtuális host lesznek a legelterjedtebbek ma még sok web site használja az IP cím alapú virtuális host-okat. Ebben az esetben nem kell a NameVirtualHost opció. Az előző példa most a következőképpen nézne ki: <VirtualHost > ServerName ServerAdmin [email protected] DocumentRoot /usr/www/site.virtual/htdocs/vevok ErrorLog /usr/www/site.virtual/nev-alapu/logs/error_log TransferLog /usr/www/site.virtual/nev-alapu/logs/access_log </VirtualHost> <VirtualHost > ServerName sales.pelda.com ServerAdmin [email protected] DocumentRoot /usr/www/site.virtual/htdocs/salesmen 78

79 ErrorLog /usr/www/site.virtual/nev-alapu/logs/error_log TransferLog /usr/www/site.virtual/nev-alapu/logs/access_log </VirtualHost> Név és IP cím alapú virtuális host-ok A fenti két módszer keverhető is: NameVirtualHost <VirtualHost ServerName ServerAdmin [email protected] DocumentRoot /usr/www/site.virtual/htdocs/vevok ErrorLog /usr/www/site.virtual/nev-alapu/logs/error_log TransferLog /usr/www/site.virtual/nev-alapu/logs/access_log </VirtualHost> <VirtualHost sales.pelda.com> ServerName sales.pelda.com ServerAdmin [email protected] DocumentRoot /usr/www/site.virtual/htdocs/salesmen ErrorLog /usr/www/site.virtual/nev-alapu/logs/error_log TransferLog /usr/www/site.virtual/nev-alapu/logs/access_log </VirtualHost> <VirtualHost > ServerName sales-ip.pelda.com ServerAdmin [email protected] DocumentRoot /usr/www/site.virtual/htdocs/salesmen ErrorLog /usr/www/site.virtual/nev-alapu/logs/error_log TransferLog /usr/www/site.virtual/nev-alapu/logs/access_log </VirtualHost> Az első két web oldalt a név alapján és a NameVirtualHost opció alapján szolgálja ki a web szerver, míg a sales-ip.pelda.com web oldalhoz a kérést a harmadik VirtualHost opció alapján szolgálja ki a web szerver. Ebben az esetben fontos, hogy az IP cím alapú virtuális host az utolsó a konfigurációs file-ban. Erre azért van szükség, mert a NameVirtualHost opció az első két virtual host-ra vonatkozik, így ha azok nem a keresett host-ok, akkor a kérés során átesik a harmadik opcióra, ami már IP alapú virtual host definíció Port alapú virtuális host-ok Ez a megoldás hasonlít az IP alapú virtual host módszerhez. Előnye, hogy nem kell több IP címet vagy nevet használni, hanem csak egy IP címre van szükség. Hátránya, hogy az emberek nem szeretnek mindenféle portot megadni a web oldal eléréshez. Például: Listen 80 Listen 8080 <VirtualHost :80> ServerName 79

80 ServerAdmin DocumentRoot /usr/www/site.virtual/htdocs/vevok ErrorLog /usr/www/site.virtual/nev-alapu/logs/error_log TransferLog /usr/www/site.virtual/nev-alapu/logs/access_log </VirtualHost> <VirtualHost :8080> ServerName sales.pelda.com ServerAdmin DocumentRoot /usr/www/site.virtual/htdocs/salesmen ErrorLog /usr/www/site.virtual/nev-alapu/logs/error_log TransferLog /usr/www/site.virtual/nev-alapu/logs/access_log </VirtualHost> 80

81 10. Fejezet DNS szolgáltatás A DNS jelentése: Domain Name Service vagyis domain név szolgáltatás. A név szolgáltatást szinte kizárólag a BIND programmal végzik az Interneten. A BIND is egy rövidítés: Berkeley Internet Name Daemons. A BIND program jelenlegi verziója Domain nevek Az Internet domain-ekből áll, amelyek hierarchiába rendeződnek. Legfelül a root domain van. Ebben is nagyon hasonlít lényegében egy Unix file rendszerhez. A ábra mutat egy példa hierarchiát. A domain neveket a specifikustól az általános felé írjuk, például: A pmmf.hu domainben van egy www és egy mail szerver, míg hu domain-nek több al-domainje is van. Ezeket a neveket nem szokták FQDN (fully qualified domain name) formátumban megadni: "www"."pmmf"."hu"."" A fenti írásmódban azért használjuk a dupla aposztrofot, hogy hangsúlyozzuk, hogy a végén ott a root csomópont. A root csomópont a "" (null) és az elválasztó jel a pont (.). Általában nem így szoktuk leírni a domain nevet, hanem: Itt azt vegyük észre, hogy a pont eltűnt a végéről! org hu uk com pmmf pte www mail ábra: Domain név hierarchia 81

82 hu gov Budaörs Budapest Pécs ábra: Feltételezett gov.hu zóna 10.2 DNS adminisztráció alapjai Mivel most már tudjuk, hogyan épül fel a domain név, az lehet a kérdés, hogy ki adminisztrálja, tartja nyílván ezeket a neveket. Egy személy esetleg? Nem. Van egy központi szervezet, ami bizonyos domain neveket adminisztrál, de nem mindet! Ez az intézmény az ICANN (Internet Corporation for Assigned Names and Numbers). Egy intézmény számára hihetetlen nagy munka volna karbantartani az összes domain nevet, illetve nagyon sérülékeny is lenne a rendszer. Így valójában a központi szervezet delegálja a feladatokat. A domain névért így felelős lehet maga a céged, de sokkal gyakoribb, hogy az Internet Szolgáltató (Internet Service Provider, ISP) felügyeli a domain neveket. Vegyük azt a példát, hogy elég nagy cégnek dolgozik, így maga a cég adminisztrálja a saját domain nevét. Ebben az esetben könnyen tudunk további al-domain-t hozzáadni, például: sales.mycompany.co.hu tech.mycompany.co.hu Így ha akarjuk a két szervezeti csoportnak külön web szervere lehet illetve további gépek tartozhatnak ezekbe az al-domain-ekbe. Mivel mi felügyeljük ezt a domain-t ezért könnyen konfigurálhatjuk a saját DNS szerverünket és nem kell kapcsolatba lépni az ICANN szervezettel. Ez a példa felveti a domain és zonák közötti különbség kérdését. Egy név szervernek teljes ismerete van a domain-ről és teljes autoritással bír felette ezért ezt a domain-t zónának szokták nevezni. Nézzünk egy összetettebb példát. A gov.hu domain delegálhatja a felügyeletet a városi önkormányzatoknak a saját domain-jeik felett. Így Budapest lesz felelős a budapest.gov.hu domain-ért és Pécs lesz felelős a pecs.gov.hu domain-ért. Mindegyik önkormányzat a saját zonájáért felelős és ez így is van jól, mivel annak semmi értelme, hogy Pécs lenne felelős Budapest domain neveiért. Ezzel a delegálási módszerrel a gov.hu domain adminisztrátorának csak annyit kell tudnia, hogy ki a felelős Budapest és Pécs domain-jeiért. Ez a delegálás azzal is jár, hogy megbízunk az al-domain-ek adminisztrátoraiban. Ami komplikálja ezt a képet, hogy nem minden önkormányzat domain-jét kezelik helyileg, mert például lehet, hogy nincs elég ismeretük hozzá, vagy nem akarják. Ebben az esetben is a gov.hu domain kezeli az al-domain-t. Ez azt jelenti, hogy egy név szerver tehát nem csak a saját, hanem az al-domain-jeit is kezelheti. Így azt lehet látni, hogy a zóna fogalma nem korlátozódik egy domain-re, annál szélesebb! Erre mutat példát a ábra Név feloldás A név feloldást name resolution -nak hívják angolul és azt jelenti, hogy megkeressük a megadott névhez tartozó IP címet. A keresésben a kliens feladata, hogy elindítsa a keresést, mivel a kliens 82

83 szinte semmit nem tud. Egy név szervernek kell majd a keresett információt szolgáltatnia. Igen, de egy név szerver csak a saját zónájába tartozó nevekről tud információt adni, így azt is biztosítania kell, hogy keresni tudjunk abban a névtartományokban is amelyek felett az adott név szervernek nincs felügyeleti jogköre. Mint már tárgyaltuk egyetlen név szerver nem tudja az egész Internetet kiszolgálni. Ugyanakkor vannak root szerverek, melyek a keresés kezdőpontjaként szolgálnak és azt adják meg, hogy kihez kell továbbítani az adott domain-re vonatkozó keresést. Nézzük meg a domain név feloldását. Az első kérdés, hogy ki felügyeli a domain-t. Ennek megtalálására a dig parancsot lehet használni: $ dig NS au. A parancs kilistázza azon név szervereket akik felügyelik az Ausztrál domain-t: au IN NS udns4.ausregistry.net.au. au IN NS udns2.ausregistry.net.au. au IN NS ns1.ausdns.net.au. au IN NS ns2.ausdns.net.au. au IN NS a1.ausdns.net.au. au IN NS udns1.ausregistry.net.au. au IN NS ab.ausdns.net.au. au IN NS udns3.ausregistry.net.au. au IN NS udns5.ausregistry.net.au. 83

84 84

85 11. Fejezet NFS és NIS szolgáltatások 11.1 NFS alapok Az NFS rövidítés a network filesystem-et vagyis hálózati filerendszert jelenti. Az NFS az RPC (Remote Procedure Call) protokollon alapul és 1980 környékén a SUN Microsystem fejlesztette ki, hogy file-okat lehessen megosztani Unix rendszerek között. Az NFS kliens-szerver architektúrát használva azt biztosítja, hogy a szerver által megosztott könyvtárak transzparens módon beilleszthetők (mount) a kliens gépek könyvtár szerkezetébe. A rendszer több daemon-t és konfigurációs file-t használ mindenféle autentikáció nélkül, így bár kényelmi szolgáltatás, de alapvetően biztonsági problémát is jelent. Az NFS protokoll felépítése a ábrán látható. NFS az UDP protokollt használja, ami egy kapcsolat nélküli (connectionless) protokoll. Az NFS-hez az úgynevezett MOUNT protokollra is szükség van amit a mountd daemon implementál. A mountd daemon mondja meg az nfsd daemon-nak, hogy mely file rendszerek állnak kliensek rendelkezésre, hogy becsatolják. A szerveren még fut a portmap daemon is, ami az RPC hívásokat kezeli. A kliens oldalon az rpc.statd és rpc.lockd daemon-ok futnak NIS alapok NIS vagyis más szóval a Network Information Service. A szolgáltatás régi neve Yellow Pages és tulajdonképpen egy adatbázis, ami lehetővé teszi a passwd, group és hosts file-ok központosított elérését. Egy központi, mester szerver (master server) tárolja az adatokat és szolgálja ki a kéréseket a kliensek felé. Ugyanakkor a mester szerver és a kliensek mellett további al-szerverek (slave server) is részei a hálózatnak, ahogy ez a??. ábrán is látható. Az al-szerverek szintén ki tudnak szolgálni kéréseket, ha a mester szerver nem elérhető, de nem tudják módosítani az adatokat. Az adatok módosítása NIS NFS RPC XDR - External Data Representation Internet protokoll Network Transport (pl. Ethernet) ábra: NFS protokoll stack 85

86 csak a mester szerveren lehetséges, ami aztán továbbítódik az al-szerverek felé. Az NIS szolgáltatás is több daemon-t használ. A szerveren az ypserv daemon fut, míg a kliens gépekről az ypbind daemon küldi a kéréseket a szerver felé. Az adatok továbbítása történhet explicit módon az yppush segítségével vagy automatikusan az ypxfrd programmal Problémák az NFS-es és NIS-el Az NFS és NIS szolgáltatásokkal több biztonsági probléma van, és ezek évek során folyamatosan problémát okoztak. Sajnos a problémák a rendszer természetéből adódnak. Például az NFS rendszer az AUTH_UNIX módszert használja az autentikációra és alapvetően megbízik az az NFS által szolgáltatott UID és GID értékben! Ezzel az a probléma, hogy könnyű olyan programot írni, amely tetszőleges UID és GID értéket használ és így az NFS szerverről bármilyen file-hoz hozzáférhetünk. Ezen felül, egy időben az NFS daemon programokban több buffer overflow hibát találtak. Az NIS szolgáltatásnál az egyik alapvető probléma a DOS (Denial Of Service) támadás. (Ezt a támadást a finger programmal lehet elérni, amikor nagyon sok kérést intézünk a szerverhez.) További problémák is vannak a szolgáltatással, de a másik fő probléma, hogy teljesen kívülállók is viszonylag egyszerűen be tudnak törni. Ha valaki kitalálja az NIS szerver címét, akkor a saját kliensével csatlakozik hozzá, majd egyszerűen az ypcat paranccsal lekérdezheti a teljes adatbázist. A fentieken kívül, mivel mindkét szolgáltatás futtatható nem priviligizált portokon ezért bármelyik felhasználó futtathatja a szolgáltatásokat. Így az eredeti szolgáltatások viszonylag egyszerűen helyettesíthetők saját verzióval, és így egy rosszindulatú felhasználó szabadon hozzáférhet a szolgáltatásokhoz. 86

87 12. Fejezet LDAP Az LDAP teljes neve: Lightweight Directory Access Protocol. Ez azt jelenti, hogy ez egy protocol ami támogatja a directory szolgáltatást (címtár szolgáltatás). A címtár szolgáltatás a legjobban ahhoz hasonló, mint egy telefon szolgáltató cég adatbázisa, amiből a felhasználókról tudhatunk meg információkat gyorsan és egyszerűen. Hagyományosan az operátor a kapcsolat a felhasználó és az adatbázis között. Ugyanakkor ez a szolgáltatás nem arra való, hogy a felhasználó a telefonszámát megváltoztassa, hanem információ kikérésre. A címtár szolgáltatásoknak speciális az adatbázisa, mivel keresésre vannak optimalizálva. Akkor használunk ilyen adatbázist amikor kevés az írás és módosítás művelet és nagy számú, gyors lekérdezésekre van szükség. A címtárak speciális tulajdonságai: Az adatbázis optimalizálva olvasásra. Természetesen írni is lehet, de számításigényes. Fejlett és összetett keresést tesz lehetővé. Az alapvető adat szerkezet kiegészíthető, úgynevezett sémákkal (schema), a helyi igényeknek megfelelően. Szabványosított formátumot és protokolt használt, így lehetőség van rendszerek közötti együttműködésre. Támogatja az egyszerű adat replikálást, többszörözést. Ezeken felül ezek az adatbázisok nem támogatják a tranzakciókezelést és a visszaforgatást. Az LDAP rendszerek eredete az X.500-as directory szolgáltatásoktól származtatható, de ugyanakkor egyszerűbb: A TCP/IP hálózaton fut. Az X.500-as rendszerek a DAP protokollt használják. Csak a legfontosabb szolgáltatások vannak megvalósítva. Adatformátuma szöveges és egyszerűbb. Fontos, hogy az LDAP csak egy protokoll és nem szoftver. A protokoll csak a címtár szolgáltatáshoz való hozzáférést szabályozza. A protokoll egy konkrét programban van megvalósítva és az adatok tárolására szolgáló adatbázist is egy másik programnak kell biztosítania. Ez az adatbázis a back end. Az LDAP protokolt először 1990-ben implementálták a University of Michigen-en. A szabad forrású implementácója az OpenLDAP ( Az OpenLDAP implementáció több részből és ezakből a legfontosabbak: démonok (daemon): slapd az OpenLDAP daemon és slurpd az adat replikáló daemon adatbázis környezet: Az OpenLDAP támogatja a Berkeley DB és GNU GDBM adatbázisokat 87

88 dc=net dc=hu szervezet dc=example szervezeti egység ou=people ou=groups személy uid=smith ábra: Információ faszerkezetben, LDAP alatt. segítő programok (utility): ldapadd (bejegyzés hozzáadása), ldapmodify (bejegyzés módosítása), ldapdelete (törlés), ldapsearch (keresés), ldappasswd (jelszó váltás). kapcsolódó segító programok: slapdpasswd (kódolt jelszavak generálása) konfigurációs file-ok Címtár szerkezete Az LDAP az információt egy faszerkezetben tárolja, ahol minden csomópont egy bejegyzés (entry). A bejegyzésnek van típusa, amely meghatározza a bejegyzésnek milyen attribútumai, tulajdonságai lehetnek. Minden bejegyzésre lehet hivatkozni a Distinguished Name (DN) segítségével. A DN lényegében a csúcshoz vezető útvonalat adja meg. Egy példa faszerkezet a ábrán látható. Mivel az adatokat nem ilyen grafikusan formában ábrázoljuk, hanem szöveges file-ban ezért minden csomópontot pontosan meg kell adnunk, hogy hol helyezkedik el a faszerkezetben. Az egyik elterjedt formátum az LDIF. Az LDIF (LDAP Data Interchange Format) formátum az RFC 2849-es dokumenumban van definiálva. 1 A formátum egyszerű szöveges dokumentumot definiál amiben ASCII karaktereket lehet használni, vagy az egyéb karaktereket base64-es kódolásban. Az LDIF formátumot az LDAP szolgáltatáson kívül a Netscape Communicator használta és a Mozilla Application Suite jelenleg is használja az címek tárolására Sémák 12.2 Szerver telepítés és beállítás Az OpenLDAP telepítése nem bonyolult, de időt vehet igénybe minden megfelelő beállítása. OpenLDAP telepítésének előfeltétele a következő szoftverek: Az Adatbázis kezelő: 1 Bár több kiegészítést javasoltak az évek során, egyelőre csak az RFC 4525-ös számú dokumentum van hivatalosan elfogadva. 88

89 Rövidítés Angol név Magyarázat cn Common Name Az egyedi objektumra hivatkozik, például személy neve, szoba, amire majd keresni fogunk. ou Organizational Unit Az a szervezeti egység aminek a személyek részei. dc Domain Component Egy domain komponense. Például a így írnánk le: dc=www,dc=google,dc=com dn Distinguished Name Ez az az egyedi név, amivel a címtár egy bejegyzésére egyedi módon hivatkozhatunk. RDN Relative Distinguished Name UPN User Principal Name tábla: LDAP nevek GNU gdbm: Berkeley DB: Transport Layer Security (TLS/SSL): Cyrus SASL könyvtár: Debian alatt a következő csomagokat kell és érdemes telepíteni a szerverre: apt-get install slapd ldap-utils migrationtools illetve még az NSCD daemon-ra is szükség lehet, a gyorsabb hozzáférés miatt. A migrationtools csomag segítségével a már létező felhasználókat lehet átvinni az LDAP adatbázisba. Az installálás során a csomag létrehoz egy külön felhasználót és csoportot és az LDAP rendszer filejai ehhez a felhasználóhoz fognak tartozni. Ha kézi úton szeretnénk ezeket a beállításokat elvégezni akkor a következő utasítás sorozatot kellene kiadni: # adduser openldap # chown -R openldap:openldap /etc/ldap # chmod 770 /etc/ldap # find /etc/ldap -type f -exec chmod 440 {} \; # find /etc/ldap -type d -exec chmod 770 {} \; # chown -R openldap:openldap /var/lib/ldap # chmod 750 /var/lib/ldap # rm /var/lib/ldap/* # chown -R openldap:openldap /var/spool/slurpd # rm /var/spool/slurpd/* LDAP szerver beállítása A telepítés után be kell állítani az LDAP szervert. A konfigurációs file általában a /etc/ldap/slapd.conf helyen található. Egy minta konfigurációs file a táblázatban látható. Az első négy sor a használt sémákat tölti be. A pidfile opció adja meg, hogy a szerver processzus azonosítóját melyik file-ban tároljuk. Az argsfile opcióval az slapd szerver argumentumait lehet megadni. A back end adatbázis helyét a directory opcióval adhatjuk meg. Az így megadott könyvtárnak a LDAP szerver indítása előtt már léteznie kell és a jogosultsága olyan legyen, hogy csak a tulajdonos felhasználó írhassa, olvashassa (mode 700), illetve legyen az LDAP felhasználó tulajdonában. A backend és database opciókkal az adatbázist adjuk meg. 89

90 include include include include pidfile argsfile directory backend database suffix rootdn rootpw /etc/openldap/schema/core.schema /etc/openldap/schema/cosine.schema /etc/openldap/schema/inetorgperson.schema /etc/openldap/schema/nis.schema /var/run/slapd/slapd.pid /var/run/slapd/slapd.args /var/lib/ldap hdb hdb "dc=example,dc=hu" "cn=admin,dc=example,dc=hu" {MD5}blablablabla== # opcionálisan password-hash {MD5} schemacheck on index objectclass eq loglevel tábla: slapd konfigurációs file ACL beállítások Kontrollálhatjuk, hogy az LDAP egyes részeihez, ki milyen jogokkal férhessen hozzá. Erre azért van szükség, mert a címtár olyan adatokat is tárol, melyre több programnak is szüksége van és anonymous módon akarjuk kiolvasni (pl. felhasználói és csoport azonosító), de ugyanitt tároljuk az érzékeny adatokat is (pl. jelszavak), amelyeket csak maga a felhasználó és az adminisztrátor érhet el. A hozzáférést nagyon finoman lehet szabályozni Például a jelszavakat védelmét a következő módon lehet megadni: access to attrs=userpassword by dn="cn=admin,dc=example,dc=hu" write by anonymous auth by self write by * none Ez a beállítás az /etc/ldap/slapd.conf file-ban azt adja meg, hogy a jelszó attribútum esetén az adminisztrátornak és magának a felhasználónak írási joga van, a névtelen felhasználónak (anonymous) azonosítania kell magát és mindenki más sem írni sem olvasni nem tudja a jelszavakat. Ha azt akarjuk biztosítani, hogy csak az adminisztrátor tudja írni a címtárat, de mindenki más olvashassa (az előző kötöttséggel, hogy a jelszavakat nem), akkor a következő sorokat kell még elhelyezni az /etc/ldap/slapd.conf file-ba: access to * by dn="cn=admin,dc=example,dc=hu" write by * read Az alap beállítás az LDAP szerver esetén: access to * by * read 90

91 vagyis mindenkinek szabad olvasási hozzáférést biztosít a teljes címtárhoz. Ezeknél a hozzáférési beállításoknál figyelni kell arra, hogy a rendszer fentről lefelé alkalmazza a szabályokat és amire van már beállítás azt az alatta levő beállítás már nem írja felül. Ezek tükrében érdemes végiggondolni a beállításokat, hogy mihez engedünk hozzéférést és mihez nem. Jelszavak generálása LDAP-hoz Ahhoz, hogy az /etc/ldap/slapd.conf file-ban vagy a címtárban meg tudjunk adni kódolt jelszavakat a slappasswd programot lehet használni. A programnak meg lehet adni, hogy crypt, MD5, SHA vagy SSHA formátumban akarjuk a kódolt jelszót megkapni. Például egy képzeletbeli jelszó esetén ezt kapjuk: $ slappasswd -h {MD5} New password: Re-enter new password: {MD5}adkjhieruhaldsjfbasdfef== (A program a szabványos kimenetre nyomtatja az eredményt, ami átírányíthatunk egy file-ba és így elmenthetjük.) 12.3 Címtár feltöltése Az LDAP címtár gyökere, maga a szervezet: 2 dn: dc=example.dc=hu objectclass: dcobject objectclass: organization o: Ez egy pelda szervezet A gyökéren kívül, magát az adminisztrátort is hozzá kell adni a címtárhoz: dn: cn=admin,dc=example,dc=hu objectclass: organizationalrole cn: admin A két alapvető bejegyzésen kívül a többi bejegyzés már opcionális és többféleképpen elrendezhető. (Persze ahhoz, hogy az operációs rendszer valamilyen alrendszere használni tudja a bejegyzéseket, ahhoz megfelelő formába kell rendezni őket.) Például a felhasználók nyilvántartásához szükséges két további bejegyzés, egy a felhasználóknak és egy a csoportoknak: dn: ou=groups,dc=example,dc=hu ou: Groups cn: Csoportok objectclass: organizationalrole description: Felhasznaloi csoportok dn: ou=people,dc=example,dc=hu ou: People cn: Emberek objectclass: organizationalrole description: Ceg felhasznaloi 2 A következő szövegrészeket lehet egy file-ba, vagy külön-külön file-okba rakni rakni. 91

92 Hozzáadó parancsok Ha bejegyzést szeretnénk a címtárhoz hozzáadni, akkor az ldapadd parancsot lehet használni. A bejegyzéseket mentsük el egy file-ba, majd a következő paranccsal adjuk hozzá: $ ldapadd -x -W -D "cn=admin,dc=example,dc=hu" -f /tmp/bejegyzesek.ldif Az egyes opciók jelentése: -x : Egyszerű azonosítást hasznájunk, ne SASL-t (lásd bekezdés). -W : Az egyszerű azonosításhoz a jelszót rejtett módon kérjük be és ne a parancssorban, nyitott szövegként. -D : Megadja azt a dn mezőt, amivel a kapcsolódáshoz szükséges felhasználót egyértelműen megadjuk. -f : Ezzel az opcióval adjuk meg, hogy melyik file-ban találhatóak a bejegyzések Felhasználók a címtárban Egy felhasználó bejegyzését a következőképpen lehet megadni LDIF formátumban: dn: uid=smith,ou=people,dc=example,dc=hu uid: smith cn: John Smith objectclass: top objectclass: account objectclass: posixaccount objectclass: shadowaccount uidnumber: 5000 gidnumber: 100 gecos: John Smith felhasznalo homedirectory: /home/smith loginshell: /bin/sh userpassword: {MD5}blablabla== shadowlastchange: 0 shadowmax: shadowwarning: 7 Egy csoport definíciója: dn: cn=loosers,ou=groups,dc=example,dc=hu objectclass: posixgroup cn: loosers gidnumber: 1100 description: Group of loosers Fontos, hogy az uidnumber nem szerepelhet a /etc/passwd file-ban mint uid (felhasználói azonosító), illetve a gidnumber már definiálva legyen vagy a /etc/group file-ban vagy az LDAP adatbázisban Egyéb parancsok Bejegyzések módosítására az ldapmodify parancs, míg egy bejegyzés törlésére az ldapdelete parancs használható. 92

93 12.4 LDAP egyszerű használata Ha root-ként szeretnénk a teljes adatbázist kiírni LDIF formátumban, akkor a slapcat parancsot lehet használni. A parancs a szabványos kimenetre írja ki a címtárat, az adatbázis sorrendjében és nem a hierarchia sorrendjében. Ezért az így kapott kimenetet szerkeszteni kell, ha az ldapadd paranccsal akarjuk használni. Ha a címtárat egy file-ba szeretnénk elmenteni, tárolás szemponjából, akkor a -l opció használható: $ slapcat -l /root/backup/ldap.ldif Az elmentett címtár visszaállítására a slapadd parancs használható: $ slapadd -l /root/backup/ldap.ldif Arra figyelni kell, hogy a slapadd parancs nem végez ellenőrzéseket a neveken illetve a sémán! Így általában az ldapadd parancsot használjuk, ha a címtárhoz hozzá akarunk adni egy bejegyzést! Keresés a címtárban Az LDAP címtárban a keresésre az ldapsearch parancs használható. A parancs kapcsolatot nyit (binding) az LDAP szerver felé és a megadott paraméterek alapján a keresés végrehajtódik. Ha minden bejegyzést szeretnénk lekérdezni a következő parancsot lehet kiadni: $ ldapsearch -x ahol a -x opció azt jelenti, hogy egyszerű azonosítást használjunk, de pedig SASL-t. 3 Egy kereséshez három dolgot kell megadni: a keresés kezdete (base): egy DN ahol a keresést kezdeni kell. Csak az adott csomópont alatti bejegyzésekben történik a keresés. keresési hatókör (scope): base: csak a gyökér csomópont szerepel a keresésben. Csak egy vagy nulla bejegyzést ad vissza a keresés. one: a DN által megadott bejegyzésben és az egy szinttel alatta levő bejegyzésekben végez keresést. sub: a DN-től indulva az alatta levő teljes alfában keres. szűrő: A szűrő formátumát az RFC 4515-ös dokumentum adja meg. Ha nem adunk meg szűrőt, akkor az (objectclass=*), vagyis a mindent kereső, szűrő lesz érvényes. Keresési példák A gyökér bejegyzés lekérése: $ ldapsearch -x -b "dc=example,dc=hu" -s base 3 A fenti ACL beállítások ( bekezdés) esetén egy felhasználó is ki tudja nyomtatni a teljes címtárat. 93

94 12.5 Felhasználó azonosítás LDAP alapján A következő csomagokat kell installálni egy kliens gépen, mely LDAP autentikációt akar használni: apt-get install libnss-ldap ldap-utils A beállítás során a kliens gépet úgy állítjuk be, hogy a felhasználó azonosítására nem csak az LDAP szerver lesz alkalmas, hanem a lokális file-ok is megmaradnak. Érdemes ezt mindig követni, mert így mindig lesz legalább egy felhasználó amivel be tudunk jelentkezni a gépre ha az LDAP szerver nem elérhető. A root felhasználó is importálható az LDAP adatbázisba, de tartsuk meg a lokális file-okban is. Az /etc/nsswitch.conf file-ban meg kell adni, hogy mely adatok esetén akarjuk az LDAP adatbázisát használni. Például felhasználók esetén a felhasználói név és adatok (passwd), csoportazonosítók (group) és maga a jelszó (shadow) is elérhető lokálisan és az LDAP adatbázisban: passwd: group: shadow: files ldap files ldap files ldap Az NSS szervert (lásd 6. fejezet) is konfigurálni kell az /etc/libnss-ldap.conf file-on keresztül: host base dc=example,dc=hu uri ldap:// / rootbinddn cn=admin,dc=example,dc=hu A rootbinddn opció adja meg, hogy milyen felhasználóként akarunk csatlakozni az LDAP szerverhez, amikor a root felhasználók vagyunk. A hozzátartozó jelszó tárolható az /etc/libnss-ldap.secret file-ban. Ebben az esetben a jelszó kódolatlanul kerül a file-ba, így a tulajdonosa a root legyen és csak root tudjon hozzáférni (mode 600). Opcionális: Amit még nem adtunk meg, hogy a root-on kívül más felhasználók és programok milyen módon kapcsolódnak az LDAP szerverhez. Alapesetben anonymous-ként történik a kapcsolódás, de arra is van lehetőség, hogy ellenőrzött módon, egy adott felhasználón keresztül kapcsolódjunk az LDAP szerverhez. A felhasználói azonosító legyen: nss. Így az /etc/libnss-ldap.conf fileban a megadandó opciók: binddn cn=nss,dc=example,dc=hu bindpw a_felhasználónak_megadott_jelszó ahol a binddn annak a felhasználónak a DN nevét adja meg, akinek a nevében kapcsolódni akarunk az LDAP szerverhez. A bindpw opcióban, kódolatlanul azt a jelszót kell megadni, amelyik jelszót a felhasználónak is megadtunk az LDAP adatbázisban. (Mivel ebben a file-ban is kódolatlan jelszó van, ezért az /etc/libnss-ldap.conf file is csak a tulajdonos felhasználó (openldap) által legyen olvasható (mode 600). Természetesen ehhez a módszerhez ezt a felhasználót is hozzá kell adni az LDAP adatbázishoz és az ACL beállítások a slapd.conf file-ban a következők lehetnek: access to attribute=userpassword by dn="cn=admin,dc=example,dc=hu" write by anonymous auth by * none access to * by dn="cn=admin,dc=example,dc=hu" write by dn="cn=nss,dc=example,dc=hu" read by * auth 94

95 Ebben az esetben a root meg tudja változtatni a jelszavakat az LDAP szerveren, míg a kliensekről csak lekérdezéseket lehet végezni. Végül az /etc/ldap/ldap.conf file-ban a kliens programok számára kell megadni, hogy hol és milyen LDAP szerver érhető el. Például ha a lokális gépen található az LDAP szerver: BASE: URI: dc=example,dc=hu ldap:// LDAP kipróbálása Ebben az állapotban az LDAP rendszer már használható és végezhetünk lekérdezéseket. Például ha fel van installálva a finger csomag, akkor ellenőrizhetjük, hogy a felhasználó létezik-e: $ finger smith Login: maxldap Name: John Smith felhasznalo Directory: /home/smith/ Shell: /bin/sh Last login Mon Jun 2 16:53 (CEST) on pts/1 from some-client.subnet.hu No mail. No Plan PAM beállítása LDAP használatára Az LDAP és PAM (lásd 5. fejezet) rendszerek összekapcsolásához további programra és beállításokra van szükség. A fenti beállítások még nem biztosítják, hogy a felhasználó azonosításánál és autentikációjánál is használható. Minden esetre ehhez az alábbi csomagot kell installálni: apt-get install libpam-ldap Debian rendszeren az alábbi file-okba új sorokat kell beszúrni, hogy a PAM rendszer is figyelembe vegye az LDAP adatbázisban tárolt adatokat: /etc/pam.d/common-auth /etc/pam.d/common-password /etc/pam.d/common-session /etc/pam.d/common-account Lényegében mindenhol a pam_unix.so sorok főlé (!) kell beilleszteni a pam_ldap.so modult. A másik változtatás, hogy a pam_unix.so modul végére beillesztettük a try_first_pass kifejezést. Erre a kifejezésre azért van szükség, hogy a rendszer ne kétszer kérdezze be a jelszót, ha a jelszó nem az LDAP adatbázisban van. A kifejezés arra utasítja a pam_unix.so modult, hogy a korábban megadott jelszót használja. Így a file-ok például a következők lehetnek: # /etc/pam.d/common-account file-ban account sufficient pam_ldap.so account required pam_unix.so try_first_pass # /etc/pam.d/common-auth file-ban auth sufficient pam_ldap.so auth required pam_unix.so nullok_secure try_first_pass # /etc/pam.d/common-password file-ban password sufficient pam_ldap.so password required pam_unix.so nullok obscure md5 try_first_pass 95

96 # /etc/pam.d/common-session file-ban session sufficient pam_ldap.so session required pam_unix.so try_first_pass A sufficient opció adja meg, hogy az LDAP-os azonosítás elegendő, míg ha ez nem sikerül, akkor a jelszó azonosítás a lokális file-ok alapján már kötelező (required). Egy /etc/pam_ldap.conf file-t is létre kell hozni és kitölteni. A szerveren a file tartalma: host base dc=example,dc=hu uri ldap:// / rootbinddn cn=admin,dc=example,dc=hu scope sub pam_password md5 pam_md5 local míg a klienseken a következő lehet, feltételezve, hogy a kliensekről csak olvasni akarunk: host base dc=example,dc=hu uri ldap:// / binddn cn=nss,dc=example,dc=hu bindpw a_felhasználónak_megadott_jelszó pam_password md5 pam_md5 local A szerveren az admin felhasználó jelszava a /etc/ldap.secret file-ban tárolható, kódolatlan módon. Ez a file is csak a felhasználó által legyen olvasható (mode 600) Debian specialitás Amikor a Debian rendszer elindul az udev alrendszer az LDAP indulása előtt indul el és a címtárakból lekérdez néhány felhasználói csoportot és felhasználó meglétét. Az nsswitch.conf file-ban a felhasználók lekérdezési sorrendje: files ldap, ezért az operációs rendszer először az /etc/passwd és /etc/group file-okban keresi a felhasználókat és csoportokat, majd az LDAP szervert kérdezi le. Az udev alrendszer által keresett csoportok és felhasználók alap esetben nem találhatók sem a fileokban sem az LDAP szerveren ezért a bootolás során több hibaüzenetet kapunk és a bootolás is lassabb lesz: nss_ldap: could not connect to any LDAP server as (null) - Can t contact LDAP server nss_ldap: failed to bind to LDAP server ldap:// : Can t contact LDAP server A hiba üzenetek eltüntetéséhez, és így a bootolás felgyorsításához, a csoportokat és felhasználókat hozzá kell adni a rendszerhez. (Az LDAP-hoz nem adhatjuk, mert az LDAP rendszer még nem indult el az udev alrendszer előtt, így a file-okhoz kell hozzáadni.) A szükséges csoportokat és felhasználót a következő parancsokkal adhatjuk a rendszerhez: $ addgroup --system scanner $ addgroup --system fuse $ addgroup --system tss $ addgroup --system kvm $ addgroup --system rdma $ adduser --no-create-home --ingroup tss --disabled-password --disabled-login tss 96

97 12.6 Biztonságosabb LDAP azonosítás Az LDAP protokoll kétfajta autentikációt (felhasználó azonosítást) tesz lehetővé: egyszerű és SASL. Az egyszerű azonosítás esetén a jelszót kell megadni. Itt érdemes arra figyelni, hogy a jelszó kódolatlanul utazhat a hálózaton. Ennek elkerülésére célszerű a kapcsolatot TLS felett használni. # /etc/openldap/slapd.conf include include include /etc/openldap/schema/cosine.schema /etc/openldap/schema/inetorgperson.schema /etc/openldap/schema/nis.schema # md5-tel titkosítsd a jelszavakat password-hash {md5} # Definiáld az SSL és a TLS tulajdonságait (opcionális) TLSCertificateFile /etc/ssl/ldap.pem TLSCertificateKeyFile /etc/openldap/ssl/ldap.pem TLSCACertificateFile /etc/ssl/ldap.pem (Lejjebb...) database ldbm suffix "dc=genfic,dc=com" rootdn "cn=manager,dc=genfic,dc=com" rootpw {MD5}Xr4ilOzQ4PCOq3aQ0qbuaQ== directory /var/lib/openldap-ldbm index objectclass eq # /etc/openldap/ldap.conf BASE dc=genfic, dc=com URI ldaps://auth.genfic.com:636/ TLS_REQCERT allow SSL-tanúsítvány generálása: # cd /etc/ssl # openssl req -config /etc/ssl/openssl.cnf -new -x509 -nodes -out \ ldap.pem -keyout /etc/openldap/ssl/ldap.pem -days # chown ldap:ldap /etc/openldap/ssl/ldap.pem # /etc/conf.d/slapd OPTS="-h ldaps:// ldapi://%2fvar%2frun%2fopenldap%2fslapd.sock " 12.7 phpldapadmin 97

98 98

99 A. Függelék Felhasznált irodalom 99

100 Tárgymutató 100