Nada na documentação do pam_succeed_if parece indicar que ele suportaria múltiplas conjunções, então você precisará fazê-lo fora do módulo.
Se você estivesse escrevendo uma regra required , seria simples combiná-los criando duas regras separadas:
auth required pam_succeed_if.so user = srvuser
auth required pam_succeed_if.so use_uid user ingroup maintainers
Mas com uma regra sufficient , como em uma que termina o processamento quando um resultado positivo é retornado, isso não funcionaria, mas se transformaria em uma condição ou . Mas o PAM suporta um tipo de controle de fluxo, permitindo ignorar algumas regras com base no valor de retorno de um módulo anterior. Veja a documentação aqui .
Isso deve fluir para a regra pam_permit desde que os pam_succeed_if modules retornem true, mas pule para as regras a seguir se eles retornarem qualquer coisa, exceto um success .
auth [success=ok default=2] pam_succeed_if.so user = srvuser
auth [success=ok default=1] pam_succeed_if.so use_uid user ingroup maintainers
auth [success=done default=ignore] pam_permit.so
... # other modules
Como você pode ver, a sintaxe é horrível, e eu sugiro testar a configuração antes mesmo de tentar usá-la em qualquer lugar.
Naturalmente, para permitir que os membros de um grupo executem um processo com os privilégios de outro usuário, você não precisa necessariamente de su , sudo ou PAM.
Com as permissões usuais de arquivo, você pode criar um binário setuid e permitir que apenas membros de um determinado grupo o executem:
# chown srvuser.maintainers ls
# chmod 4510 ls
# ls -l ls
-r-s--x--- 1 srvuser maintainers 118280 Mar 26 19:03 ls
A desvantagem aqui é que, diferentemente de su e sudo , a execução de um binário setuid não é registrada em nenhum lugar e que o binário setuid pode ser modificado ou excluído por processos executados como o usuário de destino. Para contornar isso, você poderia criar um programa wrapper de função fixa simples, para registrar a execução, setuid para o destino e, em seguida, exec do comando real.