Por que usamos o opcional no PAM, mesmo que seja ignorado?

Question

Como sabemos, optional é um dos valores de controle nos arquivos de configuração do PAM.

Em linux-pam.org :

optional:
the success or failure of this module is only important if it is the only module in the stack associated with this service+type.

Estou confuso.

Aqui está o /etc/pam.d/login :

session    required     pam_selinux.so open
session    required     pam_namespace.so
session    optional     pam_keyinit.so force revoke
session    include      system-auth
session    include      postlogin
-session   optional     pam_ck_connector.so

Eu vejo duas regras com optional control com apenas ações.

Suponho que usamos somente optional para regras de finalidade não autenticadas. Está certo?

    

Answer 1

Nota importante: módulos opcionais não serão ignorados, eles serão processados, seus resultados serão ignorados, ou seja, mesmo que falhem, o processo de autenticação será vencido ser abortado.

Existem muitas situações em que você pode querer que uma ação seja realizada (um módulo a ser executado) durante a autenticação, mas, mesmo em caso de falha, você não quer que o processo de autenticação seja abortado.

Um exemplo prático é se você quiser usar o pam para abrir automaticamente um dispositivo criptografado com criptografia dm durante o login, usando a mesma senha que a senha do usuário:

auth optional pam_exec.so expose_authtok quiet /usr/sbin/cryptsetup --allow-discards open UUID=... /home/username

Observe que se required for usado em vez de optional aqui, o primeiro login será bem-sucedido, pois cryptsetup retornará 0 como seu código de saída, mas se o usuário efetuar logout e efetuar login novamente, o login falhará o dispositivo já está aberto e o cryptsetup retornará um código de saída diferente de zero. No entanto, neste caso, você ainda deseja que o login seja bem-sucedido.

Este é apenas um exemplo que me veio à mente porque eu realmente o uso, ou seja, esta não é uma situação teórica, mas esta é uma entre muitas situações em que você deseja que um módulo com falha não aborte o processo de autenticação .

    

Answer 2

Outros usos práticos, além da resposta de Marcelo :

$ grep 'auth.*optional' /etc/pam.d -R
/etc/pam.d/lightdm:auth    optional        pam_gnome_keyring.so
/etc/pam.d/lightdm:auth    optional        pam_kwallet.so
/etc/pam.d/lightdm:auth    optional        pam_kwallet5.so
/etc/pam.d/gnome-screensaver:auth optional pam_gnome_keyring.so
/etc/pam.d/login:auth       optional   pam_faildelay.so  delay=3000000
/etc/pam.d/login:auth       optional   pam_group.so
/etc/pam.d/lightdm-greeter:auth    optional        pam_gnome_keyring.so
/etc/pam.d/lightdm-greeter:auth    optional        pam_kwallet.so
/etc/pam.d/lightdm-greeter:auth    optional        pam_kwallet5.so
/etc/pam.d/unity:auth optional pam_gnome_keyring.so

Todos são de uma VM Ubuntu 16.04, onde eu nunca toquei na configuração do PAM (exceto na medida em que qualquer pacote que eu instalei possa ter, que é onde eu suspeito que as pam_kwallet* linhas vieram).

• Os módulos Keyring do GNOME e Carteira do KDE são fáceis de entender: eles desbloqueiam seu chaveiro de login, onde suas chaves SSH e GPG e suas senhas do navegador podem ser salvas.
• pam_faildelay.so oferece um excelente exemplo de um módulo ignorado que ainda fornece um feedback imediato e evidente: fazendo você esperar se você digitou a senha errada. Aqui está um módulo que você usaria normalmente como optional , já que o sucesso ou o fracasso realmente não importam muito. Mas! pam_faildelay.so suporta apenas auth , então qualquer uso normal disso seria auth optional .