Estou tendo problemas para determinar porque su não se comporta como a configuração do PAM implicaria. Em suma, usar su para se tornar outro usuário deve carregar grupos secundários de acordo com a configuração do PAM, mas pam_group não está adicionando os grupos /etc/security/group.conf , só acabamos com nossos grupos LDAP. Ao fazer o login via SSH como usuário, você tem grupos de ambas as fontes.
Nossa configuração não está muito longe do padrão do CentOS 6.5, estamos usando o SSSD para fornecer logins via Kerberos / LDAP, mas não fizemos alterações diretas em nada em /etc/pam.d , tanto quanto me lembro, as alterações foram feitas por:
authconfig --updateall --enablesssd --enablesssdauth --enablemkhomedir
Existem, é claro, /etc/pam.d/su e /etc/pam.d/sshd separadas, mas ambas incluem arquivos idênticos onde pam_group.so é chamado (incluindo system-auth e password-auth respectivamente, mas esses dois arquivos incluídos são idênticos).
A seção relevante de /etc/pam.d/su :
#%PAM-1.0
auth sufficient pam_rootok.so
auth include system-auth
A seção relevante de /etc/pam.d/sshd :
#%PAM-1.0
auth required pam_sepermit.so
auth include password-auth
No arquivo incluído:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth optional pam_group.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_sss.so use_first_pass
auth required pam_deny.so
...
Ao efetuar login via SSH, a linha pam_group.so adiciona grupos por meio de /etc/security/group.conf , adicionando o grupo 'apache' (entre outros) a qualquer pessoa que fizer login:
*;*;*;Al0000-2400;apache,devs,rvm
Ao executar su - username como root (ou sudo su - ... como qualquer outra pessoa) e se tornar outro usuário, este pam_group não parece adicionar esses grupos adicionais. De fato, onde logar como root lhe dá esses grupos (porque pam_group fez o trabalho), executar su - username resulta na perda desses grupos, porque su começa do nada e só adiciona nos grupos que recebe do PAM (LDAP grupos essencialmente, desde que pam_group não está funcionando)
Aqui você pode ver, logado como root inicialmente, eu tenho o apache (48), devs (501) e rvm (504), mas executando apenas su - para logar como root eu perco tudo menos root (0) . Além disso, logando como usuário 'bob' usando su - bob você pode ver que eu tenho muitos grupos do LDAP (mais um grupo codificado de / etc / group que funciona), mas nada de /etc/security/group.conf .
[root@dev-web pam.d]# id -G
0 48 501 504
[root@dev-web pam.d]# su -
[root@dev-web ~]# id -G
0
[root@dev-web ~]# logout
[root@dev-web pam.d]# su - bob
[bob@dev-web ~]$ id -G
1005001 10 1001000 1001001 1001002 1001003 1001004 1001005 1001008 1001009 1001010 1001011 1001012 1001017 1001018 1001025 1001027 1001028 1001033 1001034
Finalmente, o que é um login SSH como bob - novamente eu tenho o apache (48), devs (501) e rvm (504).
[bob@dev-web ~]$ id -G
1005001 10 48 501 504 1001000 1001001 1001002 1001003 1001004 1001005 1001008 1001009 1001010 1001011 1001012 1001017 1001018 1001025 1001027 1001028 1001033 1001034
Pode-se supor que a diferença entre su - username e o login com SSH é que, no caso do SSH, existe uma senha disponível para os vários módulos que usam try_first_pass e assim por diante, mas como geralmente fazemos login usando Kerberos não há senha para esses módulos.
Fornecerei mais informações (dentro do razoável) se isso ajudar a diagnosticar essa discrepância. Obrigado antecipadamente!
editar:
Eu ativei a depuração do PAM e pam_group parece não ser acionado por su - mesmo que eu desative o pam_rootok , por isso preciso logar (para ter certeza de que ele realmente tentou passar pelo restante a pilha de pam). Independentemente de onde ele está na pilha, outros itens são acionados (uma vez que pam_rootok esteja desabilitado, pois o status "suficiente" parece causar curto-circuito na pilha).
Além disso, ocorreu-me apenas testar sudo e parece ter quase o mesmo problema. Raiz pode sudo para si mesmo e manter grupos, mas sudo ing para outro usuário somente obtém grupos LDAP. /etc/pam.d/sudo inclui apenas /etc/pam.d/system-auth , que é a mesma pilha su usa, então isso não deveria ser uma surpresa. Suponho que sudo seja inteligente o suficiente para não abandonar permissões / alternar usuário se o usuário alvo for o mesmo que o usuário atual, portanto, manter grupos raiz.