Tengo un servidor donde ejecuto nslcd para consultar un servidor AD y usarlo para autorización, y esto funciona como se esperaba. Ahora introduje nscd para reducir la carga en los servidores AD. Los resultados son un poco extraños. Si estoy ejecutando el proceso nscd normalmente (como usuario nscd o incluso usuario root), el demonio no devuelve ningún resultado.
[root@ldap-auth-test ~]# id testuser1
id: testuser: No such user
Ahora, para ver por qué no funciona, intenté seguir el proceso.
strace -p 8327 -f -s 1000
y simultáneamente, volví a hacer una identificación en testuser1. Esta vez,
[root@ldap-auth-test ~]# id testuser1
uid=10004(testuser1) gid=10046(A-TESTGROUP1) groups=10046(A-TESTGROUP1) context=root:system_r:unconfined_t:SystemLow-SystemHigh
Intenté varias veces ver si esto era una coincidencia y observé que no lo es. Intenté no conectarme a los subprocesos y pude ver que nscd no funciona cuando no estoy conectado a los subprocesos. Cualquier ayuda es muy apreciada.
[root@ldap-auth-test ~]# lsb_release -a
LSB Version: :core-3.1-amd64:core-3.1-ia32:core-3.1-noarch:graphics-3.1-amd64:graphics-3.1-ia32:graphics-3.1-noarch
Distributor ID: CentOS
Description: CentOS release 5.5 (Final)
Release: 5.5
Codename: Final
PD: lo mismo he preguntadoDesbordamiento de pilaAdemás, ya que no estoy seguro de dónde preguntar. Eliminaré el irrelevante si alguien puede señalar cuál es.
EDITAR:: La ejecución de nslcd en modo de depuración mostró que, a menos que se ejecute en nscd, el demonio ni siquiera usa nslcd para realizar consultas. En resumen, una consulta no se activa en absoluto a menos que se utilice strace.
Respuesta1
SELinux tal vez - nslcd_selinux(8) - eso ayudaría a explicar una diferencia en el comportamiento cuando se ejecuta bajo strace (al igual que un proceso que esperaba ser setuid)