Вопросы Теги

Почему мы используем optional в PAM, даже если он будет проигнорирован?

Я предполагаю, что вы добавили qsub в свой $ PATH в .bashrc или .profile файлов вашего пользователя в кластере. Они не читаются при выполнении команды через ssh .

Все должно работать нормально, если вы используете полный путь к qsub : 

ssh cluster '/usr/local/bin/qsub /home/user/casedir/run_script.sge'

Очевидно, вам нужно изменить / usr / local / bin / qsub на любой путь qsub находится в вашем кластере. Если вы этого не знаете, войдите в кластер и запустите введите qsub .

2
14.02.2018, 05:25
2 ответа

Nota importante :Los módulos opcionales no serán ignorados, serán procesados, susresultadosserán ignorados, es decir, incluso si fallan, el proceso de autenticación no será abortado.

Hay muchas situaciones en las que es posible que desee que se realice una acción (que se ejecute un módulo )durante la autenticación pero, incluso en caso de falla, no desea que se cancele el proceso de autenticación.

Un ejemplo práctico es si desea utilizar pam para abrir automáticamente un dispositivo cifrado dm -durante el inicio de sesión con la misma contraseña que la contraseña del usuario:

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

Tenga en cuenta que si se usa requireden lugar de optionalaquí, el primer inicio de sesión tendrá éxito ya que cryptsetup devolverá 0 como su código de salida, pero si el usuario cierra sesión y vuelve a iniciar sesión, el inicio de sesión fallará como el dispositivo ya está abierto y cryptsetup devolverá un código de salida no -cero. Sin embargo, en este caso aún querrá que el inicio de sesión sea exitoso.

Este es solo un ejemplo que me vino a la mente porque en realidad lo uso, es decir, esta no es una situación teórica, pero esta es una entre muchas situaciones en las que desea que un módulo fallido no cancele el proceso de autenticación..

3
27.01.2020, 22:09

Otros usos prácticos, además de Respuesta 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

Estos son todos de una máquina virtual Ubuntu 16.04, donde nunca he tocado la configuración PAM (excepto en la medida en que los paquetes que instalé puedan tener, que es de donde sospecho que provienen las líneas pam_kwallet*).

  • Los módulos GNOME Keyring y KDE Wallet son fáciles de entender :desbloquean su llavero de inicio de sesión, donde se pueden guardar sus claves SSH y GPG y las contraseñas de su navegador.
  • pam_faildelay.soofrece un excelente ejemplo de un módulo ignorado que aún brinda una respuesta inmediata y evidente :que lo hace esperar si ingresa la contraseña incorrecta. Aquí hay un módulo que normalmente usaría como optional, ya que el éxito o el fracaso realmente no importan mucho. ¡Pero! pam_faildelay.sosolo admite auth, por lo que cualquier uso normal de esto sería auth optional.
0
27.01.2020, 22:09

Теги

Похожие вопросы