Az Access Server figyelmen kívül hagyja a lemezen szerkesztett post_auth szkriptet

Egy szerkesztett mac.py, amely semmit nem változtat, a szokásos első tünet. A lemezen lévő fájl nem az, amit az Access Server végrehajt; a hitelesítési szolgáltatás a szkriptet a kiszolgáló konfigurációs adatbázisából tölti be, és pontosan az a tárolt példány dönt egy bejelentkezésről. Amíg a tárolt érték nincs lecserélve, minden teszt csak azt bizonyítja, hogy a régi szkript még működik.

Három feltétel dönti el a munkát: hogy az érték valaha bekerült-e a konfigurációs adatbázisba, hogy a szolgáltatás kapott-e utasítást az újratöltésre, és hogy a módosított kód valóban minden kapcsolatnál lefut-e. Mindegyiknek más a tünete, és a rossz javítása elpazarol egy karbantartási ablakot.

A fájl forrás, nem a futó példány

Az Access Server a post-auth szkriptet a auth.module.post_auth_script kulcs alatt tartja. A fájl szerkesztése csak a munkapéldányt frissíti. A démon a tárolt értéket olvassa, ezért a módosítás láthatatlan marad, amíg nem törli a régi bejegyzést, és nem teszi az új fájlt a helyére. Az a tárolt érték az egyetlen példány, amelyet a hitelesítési szolgáltatás megvizsgál.

Olvassa el, mielőtt módosítja. Ha már megegyezik a szerkesztett fájllal, a probléma nem a tárolás, és lépjen tovább a hatókör kérdésére. Ha régebbi verziót mutat, a módosítás soha nem érte el a szolgáltatást.

./sacli -k auth.module.post_auth_script ConfigGet

Cserélje le a tárolt példányt, majd alkalmazza

Az írás előtti törlés nem díszítés. A ConfigPut a --value_file kulccsal egy lépésben lecseréli az értéket, és az ConfigDel előbb lehetetlenné teszi egy elavult vagy sérült bejegyzés hátrahagyását. A kezdés előtt őrizzen másolatot a működő szkriptről a szkriptkönyvtáron kívül.

./sacli -k auth.module.post_auth_script ConfigDel
# store the file, then apply it
./sacli -k auth.module.post_auth_script --value_file=/root/post_auth.py ConfigPut
./sacli start

Az sacli start a módosított konfigurációt a belső szolgáltatásokra alkalmazza, és ez lépteti életbe az új szkriptet. Ez nem ugyanaz, mint az egész gép vagy a démon újraindítása, és nem is helyettesíthető azzal, hacsak a módosítás nem igényli.

Használjon abszolút útvonalat az értékfájlhoz, és erősítse meg, hogy a root olvasni tudja. Az az útvonal, amely a héjból feloldódik, de a szolgáltatásfiókból nem, olyan tárolt értéket ad, amely az ConfigGet kimenetében helyesnek látszik, és az első bejelentkezésnél meghiúsul. Ellenőrizze a tárolt eredményt még egyszer az sacli start után, nem előtte.

Modulhatókör vagy kapcsolatonként: hová tartozik a lekérdezés

A Python a modulszintű utasításokat egyszer futtatja, a szkript betöltésekor. Ezért a fájl elejére írt adatbázis-lekérdezés betöltéskor olvassa a táblát, és ezt a választ tartja meg minden későbbi kapcsolat számára. Ez a második oka annak, hogy egy módosítás hatástalannak tűnik: a kód lefut, de nem akkor, amikor várja.

Tegye a lekérdezést a post_auth kezelőbe, hogy minden hitelesítésnél lefusson. Tartsa meg a dokumentált aláírást, igazítsa a kezelő által kapott hitelesítési eredményt, és ugyanazt az objektumot adja vissza, nem csupasz számot.

A kapcsolatkezelést is a kezelőn belül tartsa. Az importáláskor megnyitott kapcsolatot a kiszolgáló bezárhatja az első felhasználó bejelentkezése előtt, és a keletkező hiba elutasított hitelesítő adatnak tűnik, nem törött szkriptnek.

Két elutasítási út, egy tulajdonos

Ha a döntés helyi lekérdezés, az eredmény a Python kezelőé. Ha külső HTTP-ellenőrzés, hagyja, hogy a parancs kilépési állapota hordozza a választ: a nullától eltérő kóddal kilépő burkoló elutasítja a bejelentkezést, és az utolsó parancs állapota lesz a szkript állapota explicit exit nélkül.

Tartsa a titkot a folyamatlistán kívül. A root által olvasható fájl vagy a szolgáltatás által átadott környezeti érték biztonságosabb, mint egy argumentum, amelyet bármely helyi felhasználó kiolvashat a ps kimenetéből. Rögzítse a végpontot egy változóban a hívás előtt, hogy az elírás a konfigurációnál bukjon el, ne valaki bejelentkezése közben. Forgassa ezt a titkot úgy, mint bármely más hitelesítő adatot.

Ellenőrzésenként egy tulajdonost válasszon. Az a szkript, amely egyszerre kérdez adatbázist és hív HTTP-szolgáltatást, kinyilvánított elsőbbségi szabályt igényel arra az esetre, amikor a kettő ellentmond, különben a napló elutasítási indoka nem fog egyezni azzal, amit a felhasználónak mondtak.

Alkalmazza anélkül, hogy kizárná az adminisztrátort

Két biztosíték teszi visszafordíthatóvá a módosítást: egy második admin fiók, amely nem függ a szkripttől, és egy ismerten jó példány a szkriptkönyvtáron kívül. Alkalmazza a módosítást karbantartási ablakban, majd figyeljen meg egy próba-bejelentkezést és egy szándékos elutasítást, mielőtt lecsatlakozik. Ha a napló szintaktikai hibát mutat hitelesítési döntés helyett, a tárolt szkript törött, és minden bejelentkezés meghiúsul.

Két feltétel azt mondja, várjon: nem tudja rootként olvasni az értékfájlt, vagy nincs második útja az admin felületre. Mindkettő kis módosítást zár ki, és egyik sem érdemes tesztelésre éles kiszolgálón a nap végén. Az Access Server dokumentációja a post-auth felületet és annak támogatott mezőit tárgyalja.