Início / unix / Perguntas / 424033
Accepted
Hawk Zhang
Asked: 2018-02-14 17:52:51 +0800 CST

Por que usamos opcional no PAM mesmo que seja ignorado?

  • 772

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

De linux-pam.org :

opcional:
o sucesso ou falha deste módulo só é importante se for o único módulo na pilha associada a este serviço+tipo.

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

Vejo duas regras com optionalcontrole apenas com ações.

Presumo que usamos apenas optionalregras de propósito não autenticado. Isso está certo?

linux authentication

2 respostas

  1. Best Answer

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

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

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

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

    Observe que, se requiredfor usado em vez de optionalaqui, o primeiro login será bem-sucedido, pois o cryptsetup retornará 0 como seu código de saída, mas se o usuário fizer logout e fizer login novamente, o login falhará porque 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.

    • 4

  2. Outros usos práticos, além da resposta do 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 eles são de uma VM do Ubuntu 16.04, onde nunca toquei na configuração do PAM (exceto no que diz respeito a quaisquer pacotes que instalei, que é de onde suspeito que as pam_kwallet*linhas vieram).

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

relate perguntas