PAM - indicateur de contrôle requis et suffisant

J'étudie le PAM et je suis un peu ignorant de la signification d'une combinaison d'indicateurs de contrôle. D'après la documentation de Red Hat, nous avons:

• l'
  échec requis d'un tel PAM conduira finalement à l'échec de retour PAM-API, mais seulement après que les modules empilés restants (pour ce service et ce type) ont été appelés

• requis
  comme requis, cependant, dans le cas où un tel module renvoie une panne, le contrôle est directement renvoyé à l'application.

• un
  succès suffisant d'un tel module suffit pour satisfaire aux exigences d'authentification de la pile de modules (si un module requis antérieur a échoué, le succès de celui-ci est ignoré). Une défaillance de ce module n'est pas considérée comme fatale pour satisfaire l'application que ce type a réussi. Si le module réussit, le framework PAM renvoie immédiatement le succès à l'application sans essayer d'autres modules.

Donc, à ma connaissance, si un module requisiteéchoue, la pile entière de modules ne sera pas analysée et le contrôle sera de retour à l'application immédiatement. Si un module sufficientréussit, le reste de la pile de modules ne sera pas analysé et le contrôle sera immédiatement renvoyé à l'application. Si un module requiredéchoue, la pile entière sera analysée.

Maintenant, je ne peux pas comprendre quel sera le comportement lorsqu'un certain module requiredéchoue et qu'un autre module sufficientréussit.

PAM passe par les éléments de la pile en séquence. Il ne garde que la mémoire de l'état dans lequel il se trouve (succès ou refus, avec succès signifiant succès jusqu'à présent), pas de la façon dont il a atteint cet état.

Si un élément marqué sufficientréussit, la bibliothèque PAM arrête de traiter cette pile. Cela se produit, qu'il y ait eu des requiredéléments précédents ou non. À ce stade, PAM renvoie l'état actuel: succès si aucun requiredélément précédent n'a échoué, sinon refusé.

De même, si un élément marqué requisiteéchoue, la bibliothèque PAM arrête le traitement et renvoie un échec. À ce stade, il n'est pas pertinent de savoir si un requiredélément précédent a échoué.

En d'autres termes, cela requiredn'entraîne pas nécessairement le traitement de toute la pile. Cela signifie seulement continuer.

À mon avis, un requiredindicateur de contrôle doit toujours réussir pour qu'un module réussisse.

Un sufficientmodule marqué est ignoré s'il échoue. S'il réussit et qu'aucun requiredmodule signalé ci-dessus n'a échoué, aucun autre module du même type ne doit être vérifié et le module est considéré comme réussi. Donc, fondamentalement, le requireddrapeau a une priorité plus élevée que le sufficientdrapeau, mais ce dernier a la capacité d'arrêter de vérifier les autres si les précédents requiredont réussi.

Exemple:

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

Si les lignes 1, 2, 3 et 4 réussissent, la ligne 5 peut être ignorée et le module authréussit. Si la ligne 4 échoue, elle est ignorée et la ligne 5 est vérifiée. Si l'une des lignes 1, 2, 3 est défaillante, la ligne 4 n'est pas prise en compte.