Cordial saludo, revise un problema que se le presentó con postfix, "SASL PLAIN authentication failed" a mi se me presenta el mismo problema, lo tengo com pam y saslauthd.
"Ya lo hice funcionar, al final luis tenia razon. Como postfix trabaja "chrooteado" no podia comunicarse con saslauthd. Al final unos enlaces duros por ahi solucionaron todo, y lo deje autenticando contra saslauthd que a su vez se cuelga de pam :-D. Gracias por la ayuda." Le agradecería enormemente que me pudiera colaborar indicándome que enlaces duros hay que realizar. Atentamente Luz Marina Carvajal G. Ing de Soporte Linux tel 6917026 [EMAIL PROTECTED] ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: http://listas.inf.utfsm.cl/pipermail/linux/attachments/20060601/b1bee62e/attachment.html From [EMAIL PROTECTED] Sat Jun 3 21:36:09 2006 From: [EMAIL PROTECTED] (Manuel Torres Carmona) Date: Sat Jun 3 22:02:08 2006 Subject: Directorio Remoto In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Se ha borrado un adjunto en formato HTML... URL: http://listas.inf.utfsm.cl/pipermail/linux/attachments/20060603/1bd1de7e/attachment.html From [EMAIL PROTECTED] Sat Jun 3 22:28:25 2006 From: [EMAIL PROTECTED] (Carlos Manuel Duclos Vergara) Date: Sat Jun 3 22:16:33 2006 Subject: Problema X en debian In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Holas, > > Testing hace mucho tiempo (al menos 3 años) > me parece que solo desde Junio del anno pasado, pero no podria asegurarlo. > > Sin duda. Pero por favor. Yo creo que estas mal usando el lenguaje. Un > error de ese tipo no creo que signifique "ranas por todos lados". > la probabilidad de falla de unas empaquetaduras del sistema de alimentacion de un cohete es baja, excepto cuando las temperaturas estan en un cierto margen donde se producen microfisuras en las empaquetaduras. Esas microfisuras se expanden rapidamente al estar sometidas a ambientes de altas G (ie, cuando el cohete esta en funcionamiento). Una vez rotas las empaquetaduras, el sistema empieza a filtrar y el cuento se convierte en una tragedia. Te suena conocida la historia? > > > Cada uno ciertamente tiene sus preferencias. No por un comentario me > > > voy a alejar del proyecto que creo, a mi parecer, es uno de los > > > mejores. Es normal cometer errores. Y arreglarlos a tiempo es la gracia > > > de cualquier proyecto. No veo irresponsabilidad alguna con la seguridad > > > como usted afirma. > > > > el problema es que no es un tema menor el del sticky bit. Puede llevar a > > serias complicaciones para el usuario. Sobretodo si el pobre angelito > > encuentra en google soluciones como: > > > > "chmod ugo+w /tmp" > > Bueno. Es que si uno hace caso a todo lo que lee, estariamos intoxicados > con Cocacola o con Pepsi...Quizas al usuario que pregunto se conformo > con la primera pagina que encontro del tema. No profundizo. Es no creo > que sea problema de la distro tambien, o si? (Creo que debian va a tener > que tener voceros autorizados para escribir howtos, FAQ y cuanto > documento de ayuda para los usuarios!) > es por eso que existen las cosas con una determinada "marca". Hay alguien detras de eso que responde por lo que pasa. Y si no te gusta el sistema que usa una determinada marca o encuentras que otra se adapta mejor a tus necesidades, simplemente te cambias de marca. Funciona al menos con los detergentes, fideos, autos, aerolineas, .... no creo que las distribuciones de Linux tengan un comportamiento diferente. Pero repito, no intento criticar a Debian, al menos las veces que he usado Debian no he tenido mayores problemas (y he usado Debian y Linux en general en una variedad de bichos raros que ni te imaginas). Las veces que he tenido problemas han sido particularmente por el modo que la distribucion trata algunas cosas, como por ejemplo cuando se les ocurrio sacar a KDE de debian porque no les gustaba la licencia de QT o lo que sucede con algunos drivers para maquinas muy particulares (y en algunos casos, con sus politicas acerca de la seguridad). > > Un poco rebuscado tu ejemplo. Creo que la probabilidad debe tender a 0. > La probabilidad de que las empaquetaduras de un cohete fallen tambien. (A todo esto, empaquetaduras = sellos, para lo que no conocen el termino) El punto es que no basta con que la probabilidad de que algo ocurra sea cercana a cero, si las consecuencias de esa accion pueden ser cercanas a infinito. Imaginate una bd que es usada como backend de un sistema de autentificacion de una empresa. Es probable que cada tanto, algun proceso de la bd (que debiera ser un proceso comun y corriente, ejecutandose desde una cuenta distinta de root) necesite abrir un par de archivos temporales para ordenar las cosas, puede se incluso para guardar una tabla temporal, o el resultado de alguna operacion que se necesitara para mas adelante. Si alguien logra modificar eso, probablemente el danno que se haga sea bastante superior a lo "insignificante" del +t. > No? No me alcance a dar cuenta del proyecto que prefieres! :-) > te sorprenderia saber que en estos momentos uso OpenBSD, ni siquiera estoy usando Linux > No estaras exagerando? > No, hay cosas para las cuales no hay razones suficientes para justificar. > > 1. El sabor de debian que tiene el mentado usuario. independiente de eso, la mayoria de los Unices normales tiene un pequenno script que se ejecuta cada tanto rato y que se llama checkpermissions (o como desee llamarlo el Unix del caso). Curiosamente la mayoria de las distribuciones Linux tienen un script similar, pero la mentada distribucion parece no tenerlo. > 2. Si tiene todo al dia y desde repos. oficiales. Incluso si no tuviera todo al dia, y si solo usara repositorios "privados". El script que menciono soluciona el problema. > 3. Cuales serian los posibles paquetes afectados. No va mucho al caso, si el paquete es de la distribucion oficial seria aun peor (incluso si es testing o unstable). Y repito nuevamente, el mentado script podria minimizar el riesgo de problemas. > Aun asi, es una piedra angular el directorio /tmp ? > > Yo creo que no. Cualquier apps seria y bien construida, en la distro que > sea no usaria ese directorio para hacer cosas que necesiten algun grado > de seguridad. No se si en los proyectos que tu usas, eso ocurre. El directorio /tmp existe para generar archivos temporales. Sea quien sea que los genere o los necesite. En otros Unices /tmp es memoria swap. Pero sea cual sea el caso, no hay ningun riesgo de seguridad en usar un cuchillo o una sierra electrica si es que se siguen las instrucciones del fabricante y se utiliza para lo que fue disennada. -- http://toolchains.com/personal/blog
