Re: [l-linux] no entiendo pam.

[Alejandro Vilte <av_lists@xxxxxxxxx>]

Sr. Ernesto Novich, agradesco muchísimo por su
explicación y ejemplo. Con prácticas que realizare mas
luego creo terminare por enterder de modo casi
completo.
 Lamento no poder dedicarle mas tiempo que quisiera
para aprender sobre linux, <<debido a cuestiones
laborales>>.
 Pero cada explicación suya como de mucho otros
colisteros,siento que me /nos dan la fuerza necesaria
para seguir avanzando.

Mi respeto y cordiales saludos.
Vilte, Alejandro
Argentina.
> 
> auth     "¿Eres quien dices ser?"
> account  "¿Se cumplen las condiciones para que
> ingreses?"
> password "¿Tu clave es válida?"
> session  "¿Tu entorno de trabajo está correcto?"
> 
> A esas preguntas se puede recibir una respuesta
> definitiva "Si" o "No".
> Tan pronto haya una respuesta definitiva, culmina el
> procesamiento de la
> columna en cuestión. Cada módulo emitirá la
> respuesta en base al
> modificador que se agregue a la columna:
> 
> > *2) required=debe ser exitoso para que continue la
> > autenticación, si falla uno el usuario no es
> avisado
> > hasta que se controle todos los modulos.
> >     requisite=Si falla un modulo el usuario es
> avisado
> > con un mensaje.
> >     sufficient=Si fracasa el modulo es ignorado,
> pero
> > si fue existoso y ningun modulo required fracaso,
> el
> > usuario es autenticado.
> >     optional= no logro entenderlo
> 
> Con éstos modificadores puedes dar las respuestas
> 
> required    Si el módulo falla se obtiene respuesta
> definitiva "No" y
>             sale "por la derecha", pero si el módulo
> triunfa se obtiene
> 	    respuesta "Si, pero tengo que revisar otras
> cosas" y se
> 	    sigue hacia abajo en la columna.
> sufficient  Si el módulo falla no hay ninguna
> respuesta y se sigue hacia
>             abajo en la columna, pero si el módulo
> triunfa se obtiene
> 	    respuesta definitiva "Si" y sale "por la
> derecha".
> requisite   Si el módulo falla se indica; en
> cualquier caso se sigue
>             hacia abajo en la columna.
> 
> Así se van probando los módulos y determinando sus
> respuestas, de arriba
> hacia abajo. Si hay una "salida por la derecha", ya
> se tiene una
> respuesta definitia; si llega hasta el fondo, la
> respuesta definitiva es
> la que ofrece el último módulo de la columna.
> 
> Digamos que existen mod_A y mod_B que son capaces de
> identificarte en
> dos bases de datos diferentes A y B; cada módulo lo
> que hace es buscar
> tu nombre de usuario en la base de datos particular,
> si existes dice que
> "si" y si no existes dice que "no". Para todo
> usuario quieres ver
> _primero_ si existe en A, y si es el caso dejarlo
> entrar; y si no existe
> en A, ver si existe en B, y si es el caso dejarlo
> entrar. En caso
> contrario, pues no puede entrar. Sencillo
> 
> auth sufficient mod_A
> auth required   mod_B
> 
> Al entrar a la columna, lo primero que se hace es
> tomar las credenciales
> presentadas por el usuario y buscarlas en A. Si
> existen, el módulo
> triunfa y en virtud del sufficient, se "sale por la
> derecha" diciendo
> "Si", con lo que el usuario ha sido autenticado. Si
> las credenciales no
> existen en A, entonces mod_A falla y en virtud del
> sufficient, no dice
> nada y "sigue para abajo". En éste punto las
> credenciales se buscan en
> B; si existen, el módulo triunfa, y en virtud del
> required la respuesta
> es "Si" pero debe seguir hacia abajo y como no hay
> nada más, triunfa la
> columna, con lo que el usuario ha sido autenticado.
> Si las credenciales
> no existen B, entonces mod_B falla y en virtud del
> required, se "sale
> por la derecha" diciendo "No".
> 
> El ejemplo clásico de aplicación de ésta estrategia
> es, por ejemplo,
> cuando se tiene la base de datos de usuario en LDAP,
> pero se tiene el
> /etc/passwd como "último recurso" [3]. Así,
> típicamente se tiene
> 
> auth sufficient mod_ldap.so
> auth required   mod_unix.so
> 
> "Si las credenciales están en el LDAP, listo; si no,
> fíjate en
> /etc/passwd, y allí tiene que estar, si no no
> entra". El problema de que
> te pide la clave varias veces es muy simple: cada
> módulo _necesita_
> recibir las credenciales particulares para
> verificarlas, pero las
> _consume_ en la operación. Esto es, mod_ldap recibe
> las credenciales,
> pero en el proceso de verificarlas "las gasta", de
> modo que si _falla_
> no le queda nada a mod_unix para trabajar y por eso
> las vuelve a pedir.
> Eso puede o no tener sentido, y depende mucho de la
> configuración
> específica; es decir, puede convenir que el sistema
> pida varias claves
> para diferentes módulos, como puede convenir reusar
> la misma clave en
> todas las validaciones [4]; en tu caso, y en el
> ejemplo que hago,
> conviene que sea la misma credencial en toda la
> pila, es decir, que pida
> la clave una sola vez y la reuse tantas veces como
> sea necesario.
> 
> Si uno lee la documentación de PAM se encuentra que
> para lograr eso se
> emplea la opción use_first_pass, de modo que nos
> queda
> 
> auth sufficient mod_ldap.so
> auth required   mod_unix.so use_first_pass
> 
> Lo que debe hacerse es establecer una secuencia de
> pasos lógicos que
> deben cumplirse para autenticar, y construir la
> columna. Cada módulo
> tiene controles diferentes y se encadenan usando
> sufficiente, required,
> optional y requisite como si estuvieras escribiendo
> el 
=== message truncated ===


=====



		
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail
________________________________________________________________________
Lista de Correo <l-linux@linux.org.ve>
Visite
http://www.linux.org.ve/cgi-bin/mailman/listinfo/l-linux
para suscribirse, retirarse y leer las normas de uso.
Visite el canal IRC #velug en undernet.org para consultas interactivas