Estou tentando permitir o acesso root de um shell de usuário regular com base na execução bem-sucedida de um programa especial, e o objetivo é que ambos su e sudo respondam à nova configuração do PAM. O programa especial é o único critério para autorização.
A configuração que estou tentando no Debian 9 em /etc/pam.d/common-auth é:
auth [success=done default=die] pam_exec.so seteuid /usr/bin/whoami
... onde whoami é um programa que retorna status de sucesso como um espaço reservado para o programa especial. O resto do arquivo common-auth é comentado.
O arquivo /etc/pam.d/su possui:
auth sufficient pam_rootok.so
session required pam_env.so readenv=1
session required pam_env.so readenv=1 envfile=/etc/default/locale
session optional pam_mail.so nopen
session required pam_limits.so
@include common-auth
@include common-account
@include common-session
O resultado é que sudo será autorizado, mas su não será:
$ su
su: Permission denied
(Os mesmos resultados no Fedora 25 usando o arquivo system-auth: sudo works e su não.)
Parece que o su simplesmente se recusa a trabalhar com o pam_exec. Neste ponto, estou perdido e posso usar algumas dicas para resolver esse problema ...
Olhando através de / var / log / messages, isso é registrado quando su é tentado:
Mar 18 08:46:39 localhost kernel: [ 61.622184] audit: type=1100 audit(1489841199.166:114): pid=1107 uid=1000 auid=1000 ses=1 msg='op=PAM:authentication acct="root" exe="/bin/su" hostname=? addr=? terminal=/dev/pts/0 res=success'
Mar 18 08:46:39 localhost kernel: [ 61.622480] audit: type=1101 audit(1489841199.166:115): pid=1107 uid=1000 auid=1000 ses=1 msg='op=PAM:accounting acct="root" exe="/bin/su" hostname=? addr=? terminal=/dev/pts/0 res=success'
Mar 18 08:46:39 localhost kernel: [ 61.623224] audit: type=1103 audit(1489841199.167:116): pid=1107 uid=1000 auid=1000 ses=1 msg='op=PAM:setcred acct="root" exe="/bin/su" hostname=? addr=? terminal=/dev/pts/0 res=failed'
Para comparação, eis o que acontece com sudo :
Mar 18 08:47:00 localhost kernel: [ 82.750720] audit: type=1123 audit(1489841220.294:117): pid=1110 uid=1000 auid=1000 ses=1 msg='cwd="/home/user" cmd=67726570202D69206175646974202F7661722F6C6F672F6D65737361676573 terminal=pts/0 res=success'
Mar 18 08:47:00 localhost kernel: [ 82.751369] audit: type=1110 audit(1489841220.295:118): pid=1110 uid=0 auid=1000 ses=1 msg='op=PAM:setcred acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=failed'
Mar 18 08:47:00 localhost kernel: [ 82.751814] audit: type=1105 audit(1489841220.295:119): pid=1110 uid=0 auid=1000 ses=1 msg='op=PAM:session_open acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
UPDATE
Cheguei a uma solução que reflete a maneira como o Debian lida com esse problema, que está obtendo uma sólida determinação de sucesso ou falha apesar de vários comandos que se autenticam em diferentes contextos, como apontado pelo @hildred. Primeiro, mostrarei linhas relevantes da autenticação comum padrão do Debian:
auth [success=1 default=ignore] pam_unix.so nullok_secure
auth requisite pam_deny.so
auth required pam_permit.so
E aqui está a substituição que utiliza o prompt de autenticação do Qubes:
auth [success=1 default=ignore] pam_exec.so seteuid /usr/lib/qubes/qrexec-client-vm dom0 qubes.VMAuth /bin/grep -q ^1$
auth requisite pam_deny.so
auth required pam_permit.so
Isso "pula um" para permitir apenas o sucesso, caso contrário, negar.
A sugestão de @hildred para 'prime' a pilha com uma linha pam_permit antes da linha pam_exec (onde a decisão é feita) é menos expressiva mas também funciona e me coloca no caminho de encontrar uma solução clara.