16.17. A hibák elhárítása a MAC rendszerben

A fejlesztés fázisában bizonyos normál konfigurációval rendelkező felhasználók gondokat jeleztek. Ezeket foglaljuk most itt össze:

16.17.1. A multilabel beállítás nem adható meg a / állományrendszerre

A multilabel beállítás nem marad meg a rendszerindító (/) partíciómon!

A tapasztalatok szerint körülbelül minden ötvenedik felhasználó szembesül ezzel a problémával, és mi is találkozunk vele a kezdeti konfigurációk kialakítása során. Ennek az úgynevezett hibának a behatóbb tanulmányozása során arra jutottunk, hogy ez többnyire vagy a hibás dokumentálásból vagy a dokumentáció félreértelmezéséből ered. Független attól, hogy ez mitől is következett be, a következő lépések megtételével orvosolhatjuk:

  1. Nyissuk meg az /etc/fstab állományt és adjuk meg a rendszerindító partíciónak az ro, vagyis az írásvédett (read-only) beállítást.

  2. Indítsuk újra a gépet egyfelhasználós módban.

  3. A tunefs -l enable parancsot futtassuk le a / állományrendszeren.

  4. Indítsuk újra a rendszert normál módban.

  5. Adjuk ki a mount -urw / parancsot, majd az /etc/fstab állományban írjuk át a ro beállítást az rw értékre és megint indítsuk újra a rendszert.

  6. Alaposan nézzük át a mount parancs kimenetét és győzödjünk meg róla, hogy a multilabel opció valóban beállítódott a rendszerindító állományrendszerre.

16.17.2. A MAC után nem lehet indítani az X11 szervert

Nem indul az X, miután MAC-kel kialakítottunk egy biztonságos környezetet!

Ezt vagy a MAC partition házirendje okozza, vagy az egyik címkékeket használó házirend helytelen beállítása. A következő módon deríthetjük ki az okát:

  1. Figyelmesen olvassuk el a hibaüzenetet: ha a felhasználó az insecure osztály tagja, akkor a partition házirend lesz a bűnös. Próbáljuk meg a felhasználót visszatenni a default osztályba és a cap_mkdb paranccsal újragenerálni az adatbázist. Ha ez nem segít a problémán, akkor haladjunk tovább.

  2. Alaposan ellenőrizzük a címkékhez tartozó házirendeket. Vizsgáljuk meg, hogy a kérdeses felhasználó esetében a házirendet és az X11 alkalmazást, valamint a /dev eszközöket tényleg jól állítottuk be.

  3. Ha az iméntiek egyik sem oldja meg gondunkat, küldjük el a hibaüzenetet és a környezetünk rövid leírását a a TrustedBSD honlapjáról elérhető TrustedBSD levelezési lista vagy a FreeBSD general questions levelezési lista címére.

16.17.3. Hiba: _secure_path(3) cannot stat .login_conf

Amikor a rendszerben megpróbálok a root felhasználóról átváltani egy másik felhasználóra, a _secure_path: unable to state .login_conf hibaüzenet jelenik meg.

Ez az üzenet általában akkor látható, amikor a felhasználó nagyobb értékű címkével rendelkezik annál, mint akivé válni akar. Például vegyük a joska nevű felhasználót a rendszerben, aki az alap biba/low címkével rendelkezik. A root felhasználó, akinek biba/high címkéje van, nem láthatja joska felhasználói könyvtárát. Ez attól függetlenül megtörténik, hogy a root a su paranccsal váltott át a joska nevű felhasználóra vagy sem. Egy ilyen helyzetben a Biba sértetlenségi modellje nem fogja engedni a root felhasználóra számára, hogy láthassa a kevésbé sértetlen objektumokat.

16.17.4. A root felhasználó nem megy!

A rendszer normál vagy egyfelhasználós módban sem ismeri fel a root felhasználót. A whoami parancs 0 (nullát) ad vissza és a su parancs pedig annyit mond: who are you? (ki vagy?). Mi történhetett?

Ez csak olyankor történhet, ha a címkézési házirendet nem engedélyezzük, vagy a sysctl(8) használatával, vagy pedig a modul eltávolításával. Ha a házirendet letiltjuk vagy ideiglenesen letiltódik, akkor a bejelentkezési tulajdonságokat tároló adatbázist a label beállítás eltávolításával kell újrakonfigurálni. A login.conf állományból ne felejtsük el kivenni az összes label beállítást és a cap_mkdb paranccsal újragenerálni az adatbázist.

Ilyen akkor is előfordulhat, amikor a házirend valamilyen módon korlátozza a master.passwd állomány vagy adatbázis elérhetőségét. Ezt általában az okozza, hogy a rendszergazda az állományt olyan címke alatt módosítja, amely ütközik a rendszerben alkalmazott általános házirenddel. Ebben az esetekben a rendszer próbálja meg beolvasni a felhasználók adatait, azonban mivel közben az állomány új címkét örökölt, nem fér hozzá. Ha a sysctl(8) paranccsal letiltjuk a házirendet, minden vissza fog térni a rendes kerékvágásba.

Ha kérdése van a FreeBSD-vel kapcsolatban, a következő címre írhat (angolul): <questions@FreeBSD.org>.

Ha ezzel a dokumentummal kapcsolatban van kérdése, kérjük erre a címre írjon: <gabor@FreeBSD.org>.