PAM - wymagana i wystarczająca flaga kontrolna

Studiuję PAM i jestem trochę nieświadomy znaczenia jakiejś kombinacji flag kontrolnych. Z dokumentacji Red Hat mamy:

wymagana
awaria takiego PAM ostatecznie doprowadzi do niepowodzenia zwracania PAM-API, ale dopiero po wywołaniu pozostałych stosowych modułów (dla tej usługi i typu)

wymagane,
jak wymagane, jednak w przypadku, gdy taki moduł zwraca awarię, kontrola jest zwracana bezpośrednio do aplikacji.

wystarczający
sukces takiego modułu jest wystarczający, aby spełnić wymagania uwierzytelnienia stosu modułów (jeśli poprzedni wymagany moduł nie przejdzie pomyślnie, sukces tego modułu jest ignorowany). Awaria tego modułu nie jest uważana za krytyczną dla spełnienia wniosku, że ten typ się powiódł. Jeśli moduł się powiedzie, środowisko PAM natychmiast zwraca sukces aplikacji bez próbowania innych modułów.

Tak więc, moim zdaniem, jeśli moduł requisiteulegnie awarii, cały stos modułów nie zostanie przeanalizowany, a kontrola natychmiast powróci do aplikacji. Jeśli moduł się sufficientpowiedzie, reszta stosu modułów nie zostanie przeanalizowana, a kontrola natychmiast powróci do aplikacji. Jeśli moduł requiredulegnie awarii, cały stos zostanie przeanalizowany.

Teraz nie rozumiem, jakie będzie zachowanie, gdy jeden moduł requiredulegnie awarii, a inny moduł odniesie sufficientsukces.

authentication pam

— ludiegu
źródło

Odpowiedzi:

PAM przechodzi kolejno przez elementy na stosie. Zachowuje jedynie pamięć o tym, w jakim jest stanie (sukces lub odmowa, z sukcesem oznacza jak dotąd sukces), a nie o tym, jak osiągnął ten stan.

Jeśli element oznaczony sufficientpowiedzie się, biblioteka PAM przestaje przetwarzać ten stos. Dzieje się tak niezależnie od tego, czy były poprzednie requiredelementy, czy nie. W tym momencie PAM zwraca bieżący stan: sukces, jeśli żaden poprzedni requiredelement nie zawiódł, w przeciwnym razie odmowa.

Podobnie, jeśli element oznaczony requisitenie powiedzie się, biblioteka PAM przerwie przetwarzanie i zwróci błąd. W tym momencie nie ma znaczenia, czy poprzedni requiredelement zawiódł.

Innymi słowy, requiredniekoniecznie powoduje przetworzenie całego stosu. Oznacza tylko kontynuowanie.

— Gilles „SO- przestań być zły”
źródło

Ale jeśli jakikolwiek requiredprzedmiot zawiódł, dlaczego PAMtrzeba ciągle przechodzić przez stos? czy to w końcu i tak się nie powiedzie?

— Mohammed Noureldin,

@MohammedNoureldin Nawet jeśli próba logowania się nie powiedzie, należy wykonać pewne czynności, takie jak rejestrowanie, dodanie limitu czasu w przypadku prób użycia siły, itp. Również zwykle system nie ujawnia dokładnej przyczyny niepowodzenia, np. Patrząc na nazwa użytkownika kończy się niepowodzeniem, a następnie użytkownik jest nadal monitowany o hasło.

— Gilles „SO- przestań być zły”

Kolejność to kolejność, w jakiej są wymienione w konfiguracji?

— OrangeDog

@OrangeDog Tak. Moduł wymieniony w pierwszym wierszu jest wykonywany, a następnie wykonywany jest drugi wiersz (lub pomijany w zależności od wyniku pierwszego wiersza) itp.

— SO Gillesa - przestań być zły

Moim zdaniem requiredflaga kontrolna musi być zawsze skuteczna, aby moduł mógł odnieść sukces.

sufficientModuł oflagowany jest ignorowana, jeśli to się nie powiedzie. Jeśli zakończy się powodzeniem i żaden z requiredpowyższych flagowanych modułów nie zawiódł, nie należy sprawdzać innych modułów tego samego typu, a moduł uznaje się za pomyślny. Zasadniczo więc requiredflaga ma wyższy priorytet niż sufficientflaga, ale ta ostatnia ma możliwość zaprzestania sprawdzania pozostałych, jeśli poprzednie się requiredpowiodły.

Przykład:

1 auth       required     /lib/security/pam_nologin.so
2 auth       required     /lib/security/pam_securetty.so
3 auth       required     /lib/security/pam_env.so
4 auth       sufficient   /lib/security/pam_rhosts_auth.so
5 auth       required     /lib/security/pam_stack.so service=system-auth

Jeśli linie 1, 2, 3 i 4 są udane, wówczas linię 5 można pominąć, a moduł authpomyślnie. Jeśli linia 4 nie powiedzie się, zostanie zignorowana i linia 5 zostanie sprawdzona. Jeśli którakolwiek z linii 1, 2, 3 ulegnie awarii, linia 4 nie jest brana pod uwagę.

— dsmsk80
źródło

Myślę, że jego pytanie brzmi, co się stanie, jeśli 1 zawiedzie, a 2-4 odniesie sukces. Czy 5 działa? Jeśli 1 się powiedzie, 5 nie zostanie uruchomionych. Innymi słowy, czy „zatrzymaj się po wystarczającym powodzeniu” ma zastosowanie, jeśli poprzedni wymagany moduł zawiódł?

— cjm

Nie, moduł uwierzytelnienia zawiódłby przy takiej kombinacji.

— dsmsk80,

Pytanie nie dotyczy tego, czy autoryzacja się nie powiedzie. To będzie. Pytanie brzmi, czy moduł 5 będzie działał, zanim ta awaria zostanie zgłoszona do aplikacji.

— cjm