Cuando se ejecuta 'su – nombre de usuario', pam_group no agrega grupos adicionales desde /etc/security/group.conf pero sshd login does?

Tengo problemas para determinar por qué su no se comporta como lo implicaría la configuration de PAM. En resumen, usar su para convertirse en otro usuario debería cargar grupos secundarios según la configuration PAM, pero pam_group no agrega los grupos /etc/security/group.conf , solo terminamos con nuestros grupos LDAP. Al iniciar session a través de SSH como usuario, tiene grupos de ambas fonts.

Nuestra configuration no está muy lejos de la pnetworkingeterminada CentOS 6.5, estamos utilizando SSSD para proporcionar inicios de session a través de Kerberos / LDAP, pero no hemos realizado cambios directos a nada en /etc/pam.d por lo que recuerdo, los cambios fueron realizados por:

 authconfig --updateall --enablesssd --enablesssdauth --enablemkhomedir 

Por supuesto, hay /etc/pam.d/su y /etc/pam.d/sshd separados, pero ambos incluyen files idénticos donde se llama a pam_group.so (incluyendo system-auth y password-auth , respectivamente, pero esos dos incluidos) los files son idénticos).

La sección relevante de /etc/pam.d/su :

 #%PAM-1.0 auth sufficient pam_rootok.so auth include system-auth 

La sección relevante de /etc/pam.d/sshd :

 #%PAM-1.0 auth requinetworking pam_sepermit.so auth include password-auth 

En el file incluido:

 #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth requinetworking 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 requinetworking pam_deny.so ... 

Al iniciar session a través de SSH, la línea pam_group.so agrega grupos a través de /etc/security/group.conf , agregando el grupo 'apache' (entre otros) a cualquier persona que /etc/security/group.conf session:

 *;*;*;Al0000-2400;apache,devs,rvm 

Cuando se ejecuta su - username como root (o sudo su - ... como cualquier otra persona), y se convierte en otro usuario, este pam_group no parece agregar estos grupos adicionales. De hecho, cuando iniciar session como root le da estos grupos (porque pam_group hizo su trabajo), al ejecutar su - username resulta que perderá esos grupos, porque su comienza de la nada y solo agrega en los grupos que obtiene de PAM (grupos LDAP esencialmente , ya que pam_group no está funcionando)

Aquí puede ver, inició session como root inicialmente, tengo apache (48), devs (501) y rvm (504), pero solo estoy ejecutando su - para iniciar session como root. Perdí todo less root (0). Además, al iniciar session como usuario 'bob' usando su - bob , puede ver que tengo muchos grupos de LDAP (más un grupo codificado de / etc / group que sí funciona), pero 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, parece un SSH login como bob – otra vez tengo apache (48), devs (501) y 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 

Uno podría suponer que la diferencia entre su - username y el inicio de session con SSH es que en el caso de SSH hay una contraseña disponible para los diversos modules que usan try_first_pass y así sucesivamente, pero dado que a menudo estamos ingresando usando Kerberos, no hay contraseña para estos modules.

Proporcionaré más información (dentro de lo razonable) si esto ayuda a diagnosticar esta discrepancia. ¡Gracias por adelantado!

editar:

He activado la debugging de PAM y pam_group no parece disparar para su , incluso si desactivo pam_rootok así que tengo que iniciar session (para asegurarme de que realmente intentó pasar por el rest de la stack de pam). Independientemente de dónde se encuentre en la stack, otros elementos disparan (una vez que pam_rootok está desactivado, ya que su estado "suficiente" parece cortocircuitar la stack).

También se me ocurrió probar sudo , y parece tener casi el mismo problema. Root puede hacer sudo y mantener grupos, pero sudo a otro usuario solo obtiene grupos LDAP. /etc/pam.d/sudo solo incluye /etc/pam.d/system-auth que es la misma stack que usa, por lo que no debería ser una sorpresa. Supongo que sudo es lo suficientemente inteligente como para no soltar permissions / cambiar de usuario si el usuario objective es el mismo que el usuario actual, por lo tanto, mantener los grupos de root.

Supuse que su problema es el file su-pam y el module pam_rootok .

 #%PAM-1.0 auth sufficient pam_rootok.so auth include system-auth 

La cláusula sufficient abrevia el process de authentication. Por lo tanto, la authentication del sistema nunca se incluye, lo que significa que el module pam_group nunca se activa para esta session.

Entonces, suspiro , leo tu edición. De todos modos, definitivamente es un comienzo para resolver esto. Tal vez active la debugging de pam_group para ver si devuelve uno de los valores de error documentados ( man pam_group ).

Acerca de sudo, en realidad tiene sentido que después de autenticar al usuario a través de PAM, toda la información de la count sea ​​descartada / deshabilitada. Tiene sus propios mecanismos para agregar usuarios a grupos. Intente agregar la opción preserve_groups para la input de sudo correspondiente.

Todo esto me hace preguntarme: ¿Por qué pam hizo que el module de grupo solo fuera relevante para auth . De hecho, debería ser parte de la count .

Las líneas de authentication solo se miran al procesar una contraseña, por lo que se ignoran cuando su raíz es suya o para ssh con una key pública.

No he encontrado una manera de hacer que esto funcione.