Directorio Remoto
[EMAIL PROTECTED] wrote: > Se puede hacer que uno pueda acceder a su directorio, remotamente. Hummm > Tal como uno lo hace en una red local, por medio de samba, pero lo > que necesito es por internet, acceder a un pc que está fuera de la > red local (lejos lejos). Pero sin usar un programa de conexion, sino > que se vea en el entorno de red (Windows), o escribiendo la ruta en > URL (\\200.25.23.35\directorio), o algo por el estilo. Se puede, pero hacerlo en forma segura no es nada facil. Puedes manipular cosas remotamente usando ssh(1), scp(1); screen(1) es util tambien. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 From [EMAIL PROTECTED] Sat Jun 3 23:14:18 2006 From: [EMAIL PROTECTED] (Alvaro Herrera) Date: Sat Jun 3 23:36:16 2006 Subject: Problema X en debian In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Horst von Brand escribió: > > Aun asi, es una piedra angular el directorio /tmp ? [...] > Scrolling del tty. Archivos temporales de less(1) cuando se invoca sobre un > pipe. Archivos temporales del compilador (preprocesado, assembler). Como ya > dije, sockets de screen(1). Estos son simplemente ejemplos variados de los > que me acuerdo en el momento, may muchisimos mas. Todo esto deberia ocurrir en TMPDIR, el cual no necesariamente seria /tmp. De hecho, ponerlo en otra parte elimina de un paraguazo un monton de posibles problemas de seguridad ($HOME/tmp por ej) -- Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4 "Estoy de acuerdo contigo en que la verdad absoluta no existe... El problema es que la mentira sí existe y tu estás mintiendo" (G. Lama) From [EMAIL PROTECTED] Sat Jun 3 23:37:00 2006 From: [EMAIL PROTECTED] (Horst von Brand) Date: Sat Jun 3 23:37:08 2006 Subject: /tmp en swap [Was: Re: Problema X en debian] In-Reply-To: Your message of "Sat, 03 Jun 2006 19:28:25 MST." <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Carlos Manuel Duclos Vergara <[EMAIL PROTECTED]> wrote: [...] > El directorio /tmp existe para generar archivos temporales. Sea quien sea > que los genere o los necesite. En otros Unices /tmp es memoria swap. En Linux esta tmpfs, que hace exactamente eso. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 From [EMAIL PROTECTED] Sun Jun 4 00:39:06 2006 From: [EMAIL PROTECTED] (Horst von Brand) Date: Sun Jun 4 00:39:14 2006 Subject: Hi List. In-Reply-To: Your message of "Sat, 03 Jun 2006 23:19:08 -0400." <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Miguel Oyarzo <[EMAIL PROTECTED]> wrote: > At 20:04 03-06-2006, Hugo Figueroa R. wrote: > >la lista es en español, por que escribes en ingles? > lo hace de payaso no mas. No necesariamente... > Si en Valparaiso todos hablan espanol que yo recuerde No todos los integrantes de la lista estan en Valparaiso. Los hay en Punta Arenas, y (segun recuerdo) hasta en Suecia hay integrantes. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513
Hi List.....
lo hace de payaso no mas. Si en Valparaiso todos hablan espanol que yo recuerde Miguel Oyarzo Punta Arenas At 20:04 03-06-2006, Hugo Figueroa R. wrote: >la lista es en español, por que escribes en ingles? > >Saludos. > > --- [EMAIL PROTECTED] escribió: > >> >> >> Hi everybodyI would like to ask you.. >> >> so I am using pxe and when I configure this one >> with pxelinix.0 and this >> file read pxelinux.cfg and inside there is the >> config file default. >> it is work perfect... >> >> default file say so : >> DAFAULT Gentoo1.4 >> LABEL Gentoo1.4 >> KERNEL linux >> APPEND nfsroot=3D192.168.10.10:/tftpboot/nodo1 >> IPAPPEND 1 >> >> ... >> the problem that i have is that when I change the >> name file default to MAC >> address of the nodo 1 then not work and say Kernel >> panic, the pxelinux.0 >> not read this one (00:44:55:66:77:88) >> >> I changing again to default and work perfect.so >> what going on ? I don= >> =B4t >> undertand that... >> >> if you had the same proble or similar can you please >> tell me something to >> help me >> I will be grateful of you. >> >> many thanks list and have a nice day..!! >> >> from Chile .. >> >> >> -- >> René Harb Hoecker >> Electronic engineer >> F: 92128869 >> Valparaíso, Chile. >> >> > > >__ >Correo Yahoo! >Espacio para todos tus mensajes, antivirus y antispam ¡gratis! >Regístrate ya - http://correo.espanol.yahoo.com/
Ayuda
On Thu, 2006-06-01 at 10:19 -0500, Luz Marina Carvajal Gonzalez wrote: > 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. Dependiendo de tu configuración, postfix podría estar ejecutándose en una jaula chroot dentro de /var/spool/postfix. Por lo tanto, todo lo que busque, será en relación a dicho directorio. Por ejemplo, puedes indicar a saslauthd que utilice el directorio /var/spool/postfix/var/run/saslauthd para crear los sockets de comunicación con los programas, en vez de /var/run/saslauthd Luego, /var/run/saslauthd puede ser un enlace simbólico a /var/spool/postfix/var/run/saslauthd. -- Germán Poó-Caamaño http://www.ubiobio.cl/~gpoo/ Concepción - Chile
Ayuda
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 b
Montar partición FAT
Juan Pablo San MartÃn <[EMAIL PROTECTED]> wrote: > Hola, he intentado montar unas particiones FAT en linux, la distro es > Centos. Pero solo logro montarlas como de lectura, pero escritura no > hay caso. Curioso. Versiones exactas de la distro? De donde salen estas particiones? Notese que los permisos en VFAT (y otros sistemas de archivo que no saben de usuarios) dependen de quien monto, si monta root, nadie mas puede hacer nada. Etc. Mira las opciones bajo "Mount options for fat" y "... for vfat" en mount(8). -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 From [EMAIL PROTECTED] Sat Jun 3 20:04:50 2006 From: [EMAIL PROTECTED] (Hugo Figueroa R.) Date: Sat Jun 3 20:31:35 2006 Subject: Hi List. In-Reply-To: <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> la lista es en español, por que escribes en ingles? Saludos. --- [EMAIL PROTECTED] escribió: > > > Hi everybodyI would like to ask you.. > > so I am using pxe and when I configure this one > with pxelinix.0 and this > file read pxelinux.cfg and inside there is the > config file default. > it is work perfect... > > default file say so : > DAFAULT Gentoo1.4 > LABEL Gentoo1.4 > KERNEL linux > APPEND nfsroot=3D192.168.10.10:/tftpboot/nodo1 > IPAPPEND 1 > > ... > the problem that i have is that when I change the > name file default to MAC > address of the nodo 1 then not work and say Kernel > panic, the pxelinux.0 > not read this one (00:44:55:66:77:88) > > I changing again to default and work perfect.so > what going on ? I don= > =B4t > undertand that... > > if you had the same proble or similar can you please > tell me something to > help me > I will be grateful of you. > > many thanks list and have a nice day..!! > > from Chile .. > > > -- > René Harb Hoecker > Electronic engineer > F: 92128869 > Valparaíso, Chile. > > __ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! Regístrate ya - http://correo.espanol.yahoo.com/ From [EMAIL PROTECTED] Fri Jun 2 13:54:21 2006 From: [EMAIL PROTECTED] ([EMAIL PROTECTED]) Date: Sat Jun 3 20:44:53 2006 Subject: Directorio Remoto Message-ID: <[EMAIL PROTECTED]> Hola amigos de la lista: Se puede hacer que uno pueda acceder a su directorio, remotamente. Tal como uno lo hace en una red local, por medio de samba, pero lo que necesito es por internet, acceder a un pc que está fuera de la red local (lejos lejos). Pero sin usar un programa de conexion, sino que se vea en el entorno de red (Windows), o escribiendo la ruta en URL (\\200.25.23.35\directorio), o algo por el estilo. Muchas Gracias.
Problema X en debian
Juan MartÃnez <[EMAIL PROTECTED]> wrote: > El sáb, 03-06-2006 a las 01:10 -0700, Carlos Manuel Duclos Vergara dijo: [...] > > 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. Eso es lo comun, y /precisamente/ por esa razon es que es responsabilidad de la distribucion (o el paquete) evitar esas cosas. Y responsabilidad de quienes mas saben del tema de culturizar a quienes no saben, o corregir estos errores. Que es lo que intentamos hacer aca... > 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!) Por /algo/ los tiene... > > que claramente pueden llevar a problemas serios. Un solo ejemplo > > (inventado, apliquenlo a la situacion que se les ocurra): > > 1. /tmp con permisos ugo+w > > 2. Un servicio establece un socket para comunicacion con procesos > >ayudantes en el directorio tmp. > > 3. Un usuario "avanzado" se percata de la situacion, y se percata de > >que no hay sticky bit y procede a borrar el socket y cambiarlo por un > >nuevo socket adaptado a sus necesidades. > > 4. El "usuario avanzado" espera que uno de los procesos ayudantes se > >contacte con el socket y voila! > > > > Probablemente tomara unas 100 iteraciones dar con el momento exacto > > para borrar el socket y cambiarlo por otro, pero no es nada que un > > script y un par de cervezas no solucionen. > Un poco rebuscado tu ejemplo. Creo que la probabilidad debe tender a 0. Cuando se habla de seguridad, las "probabilidades" cuentan pocazo, queremos garantias (dentro de lo razonable). Programas en uso comun que hacen algo asi incluyen screen(1). Programas que crean archivos temporales en /tmp hay muchos, y dandoles archivos pichicateados demas se pueden lograr efectos "interesantes" en muchos casos... Simplememente cambiar de nombre a archivos temporales de "otros" puede llenar /tmp sin sobrepasar quotas > > Pregunta: Que pasa si el proceso que abrio el socket, era un proceso de > > autentificacion de usuarios? > En debian ningun socket se abre en /tmp. Para eso es /var/run Insisto: Hay programas que lo hacen. /var/run es para root unicamente, si un programa para usuarios de a pie requiere algo asi, lo hara en /tmp. Echa una mirada al FHS para la justificacion de /tmp y afines. [...] > > Solo > > quiero resaltar que lo que parece una "pequennez" puede convertirse en la > > piedra angular de muchos problemas. > > No estaras exagerando? Se nota claramente que no has mirado el "como" de alguna intrusion mas sofisticada. Y han habido ataques locales harto rebuscados tambien (Las maneras "obvias" de hacer estas cosas generalmente ya se cerraron. Bueno, eso es lo que estamos pidiendo aca...). > Las defensas coorporativas son como un poco innecesarias en estos > tiempos. Excelente. Recuerdame nunca contratarte para nada que aun lejanamente tenga alguna relevancia. > Por lo demas. Estamos hablando sin saber: > > 1. El sabor de debian que tiene el mentado usuario. > 2. Si tiene todo al dia y desde repos. oficiales. > 3. Cuales serian los posibles paquetes afectados. > > Con respecto a lo que yo afirme, me falto especificar que fue hace unos > años y que fue en testing. Sorry. 1. No importa que distribucion es, es una demostracion clarisima de manejo irresponsable de la seguridad. Posiblemente perdonable en versiones de prueba para dementes terminales, pero aun asi... 2. Ver arriba. 3. No importa demasiado (obvio, si el culpable es un paquete que solo el desarrollador y dos usuarios mas instalan es un tanto menos critico que si es el paquete de bash quien se manda la gracia... > Aun asi, es una piedra angular el directorio /tmp ? Eliminalo, y veras... > 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. Es bien comun requerir espacio temporal, y es comodo poder acceder a espacio comun siempre en forma uniforme, incluso cuando estas en un directorio en el que no tienes permisos y trabajando con archivos que solo puedes leer. > No se si en los proyectos que tu usas, eso ocurre. Scrolling del tty. Archivos temporales de less(1) cuando se invoca sobre un pipe. Archivos temporales del compilador (preprocesado, assembler). Como ya dije, sockets de screen(1). Estos son simplemente ejemplos variados de los que me acuerdo en el momento, may muchisimos mas. -- Dr. Horst H. von Brand Us
Linux en EntelPCS
Pablo Figueroa Alvarez <[EMAIL PROTECTED]> wrote: [...] > asi tambien ahy entidades gubernamentales que usan linux asi como la > aduana En Aduanas el proyecto se manejo mal, y tuvieron que echar marcha atras. Lo que paso fue que: - Pretendian tener /todo/ en la central, solo "clientes tontos" en los escritorios [En realidad, no completamente tontos, pero sin datos de usuarios] - Se hizo una encuesta para saber que tenian los usuarios, quienes comentaron de lo "oficial" que tenian, no contaron de aplicacioncitas tejidas en casa que les resultaban indispensables - Se migro todo (BigBang) a Linux... y muchas cosas fallaron (previsiblemente), partiendo de PCs que no funcionaban, impresoras no soportadas, ... Entiendo que actualmente tienen sus servidores y algunas partes de lo que son escritorios con Linux, y esto ultimo lentamente se expande. >y el INP de hecho estos ultimos estan migrando todos sus > estaciones de trabajo a linux. De eso no se nada. Detalles? [Espero que no cometan el error anterior!] Y los servidores web del gobierno (y del congreso) son casi uniformente Linux + Apache. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 From [EMAIL PROTECTED] Sat Jun 3 15:23:43 2006 From: [EMAIL PROTECTED] (=?ISO-8859-1?Q?Juan_Pablo_San_Mart=EDn?=) Date: Sat Jun 3 16:21:24 2006 Subject: =?iso-8859-1?q?Montar_partici=F3n_FAT?= Message-ID: <[EMAIL PROTECTED]> Hola, he intentado montar unas particiones FAT en linux, la distro es Centos. Pero solo logro montarlas como de lectura, pero escritura no hay caso. Les envío el archivo /etc/fstab, para que me ayuden, en caso de haber un error. # This file is edited by fstab-sync - see 'man fstab-sync' for details LABEL=/ / ext3defaults1 1 none/dev/ptsdevpts gid=5,mode=620 0 0 none/dev/shmtmpfs defaults0 0 /dev/hdb2 /mnt/hdb2 vfatrw,user,auto0 0 /dev/hdb3 /mnt/hdb3 vfatrw,user,auto0 0 /dev/hdb1 /mnt/musica vfatrw,user,auto0 0 none/proc procdefaults0 0 none/syssysfs defaults0 0 /dev/hda2 swapswapdefaults0 0 /dev/hdc/media/cdromauto pamconsole,fscontext=system_u:object_r:removable_t,exec,noauto,managed 0 0 /dev/fd0/media/floppy auto pamconsole,fscontext=system_u:object_r:removable_t,exec,noauto,managed 0 0 Saludos, y gracias de antemano. Juan Pablo
Problema X en debian
El sáb, 03-06-2006 a las 01:10 -0700, Carlos Manuel Duclos Vergara escribió: > Holas, > > > Me extraña su respuesta Sr. profesor. > > Si nadie reporta este tipo de cosas, como hacer que avance el proyecto? > > se supone que el proyecto existe para brindar un cierto nivel de > "tranquilidad" a los usuarios. Sobretodo si estaba en stable, o en testing > (que se supone ahora que tambien tiene updates desde security). Testing hace mucho tiempo (al menos 3 años) > > Es una pequeñez esto que toco, pero precisamente aqui es donde va el > > caracter principal del software libre, en la colaboracion de la comunidad. > > Me imagino que Ud. lo tiene muy claro...espero. > > lo cual no excluye la responsabilidad del autor. No porque sea un proyecto > open source se te van a filtrar ranas por todos lados 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". > > 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!) > que claramente pueden llevar a problemas serios. Un solo ejemplo (inventado, > apliquenlo a la situacion que se les ocurra): > > 1. /tmp con permisos ugo+w > 2. Un servicio establece un socket para comunicacion con procesos ayudantes > en > el directorio tmp. > 3. Un usuario "avanzado" se percata de la situacion, y se percata de que no > hay sticky bit y procede a borrar el socket y cambiarlo por un nuevo socket > adaptado a sus necesidades. > 4. El "usuario avanzado" espera que uno de los procesos ayudantes se contacte > con el socket y voila! > > Probablemente tomara unas 100 iteraciones dar con el momento exacto para > borrar el socket y cambiarlo por otro, pero no es nada que un script y un par > de cervezas no solucionen. > Un poco rebuscado tu ejemplo. Creo que la probabilidad debe tender a 0. > Pregunta: Que pasa si el proceso que abrio el socket, era un proceso de > autentificacion de usuarios? En debian ningun socket se abre en /tmp. Para eso es /var/run > En cambio, el sticky bit existe para garantizar que esa situacion no se de. A > no ser (y eso depende del sistema en cuestion, si utiliza sistemas mas > avanzados como SELinux), que seas root con lo cual el sticky bit puede ser > pasado a llevar. > Esa clase de cosas, debiera ser revisada antes de que salga a la luz publica > o > de lo contrario mas de un dolor de cabeza te vas a llevar. Pero sin duda. Yo no estoy en contra de eso, el tema es que se caen los aviones pues. > A todo esto, no tengo ninguna intencion de criticar al mentado proyecto. No? No me alcance a dar cuenta del proyecto que prefieres! :-) > Solo > quiero resaltar que lo que parece una "pequennez" puede convertirse en la > piedra angular de muchos problemas. No estaras exagerando? Las defensas coorporativas son como un poco innecesarias en estos tiempos. Por lo demas. Estamos hablando sin saber: 1. El sabor de debian que tiene el mentado usuario. 2. Si tiene todo al dia y desde repos. oficiales. 3. Cuales serian los posibles paquetes afectados. Con respecto a lo que yo afirme, me falto especificar que fue hace unos años y que fue en testing. Sorry. 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. -- Juan Martínez Depto. Inf. UMC
Problema X en debian
Juan MartÃnez <[EMAIL PROTECTED]> wrote: > El Sab, 3 de Junio de 2006, 1:29 am, Horst von Brand escribió: > > Juan MartÃÂnez <[EMAIL PROTECTED]> wrote: > >> El vie, 02-06-2006 a las 10:54 -0400, [EMAIL PROTECTED] escribió: > [...] > >>> verifique que no hubiera problemas de espacio y estaba al 50% para la > >>> raiz, > >>> despues google y encontre que era un problemas de permisos de /tmp > >>> drwxr-xr-x 13 root root 4096 Jun 2 10:42 tmp > >>> los cambie con chmod ugo+w /tmp > >> Hubiera sido mas lindo con chmod 1777 /tmp :-) > > chmod a=rwx,+t /tmp # en castellano > En gustos... La version letrada es mucho mas flexible (permite dar/quitar permisos en forma independiente, etc). > >>> y listop pero la pregunta del millon es ÿquien cambio los permisos? > > > >> Mmm...a veces (en muy contadas veces) algunos paquetes pueden cometer > >> estos cambios. Cosa rara, pero me han pasado cosas similares. Incluso > >> las he reportado. > > > > Que pasen cosas como esas para mi seria razon suficiente para alejarme > > rapidamente de los paquetes del caso, y seguramente buscar una > > distribucion > > menos irresponsable con la seguridad. > Me extraña su respuesta Sr. profesor. Cambios de permisos de directorios del sistema al instalar es algo que a mas tardar quien arma el paquete debiera pillar. > Si nadie reporta este tipo de cosas, como hacer que avance el proyecto? Esta clase de cosas /nunca/ debieran salir de las manos del desarrllador. > Es una pequeñez esto que toco, pero precisamente aqui es donde va el > caracter principal del software libre, en la colaboracion de la comunidad. Yep. > Me imagino que Ud. lo tiene muy claro...espero. Y la parte de que como desarrollador soy responsable por lo que les ocurre a cientos de miles de usuarios tambien la tengo clara. > Cada uno ciertamente tiene sus preferencias. No por un comentario No es mi comentario (esos se los lleva el viento), es el cambio irresponsable de permisos lo que debiera preocuparte. 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. Cambio de permisos == seguridad, cambio de permisos de cosas criticas... PS: Echa una miradita a la diferencia en drwxrwxrwt y drwxrwxrwx en directorios como /tmp, piensa las implicancias, considera que el usuario de a pie /no/ sabra la diferencia... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513
Linux en EntelPCS
asi tambien ahy entidades gubernamentales que usan linux asi como la aduana y el INP de hecho estos ultimos estan migrando todos sus estaciones de trabajo a linux. On 5/10/06, socken des teufel <[EMAIL PROTECTED]> wrote: > > > 2006/5/5, José F. Hidalgo C. <[EMAIL PROTECTED]>: > > > > hace algun tiempo, vi que los equipos que usan para caja en homecenter, > tambien usan linux. Lamentablemente, estaba colgado en: > > > > Give root password or press ctl d to continue > > > > :( > > > > > > > > > > El día 1/05/06, Horst von Brand <[EMAIL PROTECTED]> escribió: > > > > > Manuel E. Torres Carmona <[EMAIL PROTECTED]> wrote: > > > > En nombre de Horst von Brand: > > > > > Hoy en el local del caso en Vin~a las pantallas que suelen mostrar > > > > > videos de musica (pero en silencio... nunca entendi el sentido de > eso) > > > > > estaban mostrando un kernel panic de 2.6.9-1.667 (o algo asi, me > late a > > > > > algun Red Hat o Fedora). > > > > > > > > > > Mala manera de darse cuenta que usan Linux, pero igual! > > > > > > > Asi es. > > > > > > > Yo pase por fuera de la tienda de entel en La Serena alrededor de las > > > > 20:45 la semana pasada y vi un par de tipos jugando en esas pantallas > con > > > > un FC"X" + KDE. > > > > > > ;-) > > > > > > > Igual me sorprendio que usaran Linux para eso Estaran reduciendo > los > > > > costos del licenciamiento microsoft en entel ? Jajajaja > > > > > > Me late que pagar una o dos licencias Win mas por local les da lo mismo > > > (sera el sueldo mensual de una de las personas que alli laboran, para > que > > > les dure unos 5 an~os?). Yo apostaria que es por ahorrarse lios (mas > facil > > > de manejar, mas flexible, todo viene en el mismo paquete, ...). > > > -- > > > Dr. Horst H. von Brand User #22616 counter.li.org > > > Departamento de Informatica Fono: +56 32 654431 > > > Universidad Tecnica Federico Santa Maria +56 32 654239 > > > Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 > > > > > > > > > > > > > -- > > * > > > > José F. Hidalgo C. > > .-. Usuario Linux #358588 > > /v\Fono : 56 0 98775114 > > // \\Estudiante Ing. Civil Electrónica > > /( )\U. Técnica Federico santa María > > ^^-^^Valparaíso, Chile > > * > > > > Me extraña que se sorprendan, entel (en todas sus filiales) tiene una gran > cantidad de servidores corriendo linux, en especial red hat y no solo dando > servicio internet, hay bases de datos bastantes importantes sobre linux. > > asi komo otras "grandes" empresas como endesa, terra, telefonica, y sin > nombrar los bancos ... es soprendente la cantidad de servidores con linux, > en bases de datos (casi siempre oracle), cluter (de alta disponibilidad y > lvs) telefonica tiene un lvs de aprox 10 maquinas ... desconosco para ke lo > usan, pero ahi esta. > > o sino preguntele a la gente de linuxcenter ... > > > -- - ...--- DJ Storm ---... - Pablo Figueroa Alvarez Analista Programador Webmaster www.eskarlata.com Webmaster www.fiestasoz.cl Webmaster www.elcomst.cl Santiago - Chile -
Problema X en debian
Holas, > Me extraña su respuesta Sr. profesor. > Si nadie reporta este tipo de cosas, como hacer que avance el proyecto? > se supone que el proyecto existe para brindar un cierto nivel de "tranquilidad" a los usuarios. Sobretodo si estaba en stable, o en testing (que se supone ahora que tambien tiene updates desde security). > Es una pequeñez esto que toco, pero precisamente aqui es donde va el > caracter principal del software libre, en la colaboracion de la comunidad. > Me imagino que Ud. lo tiene muy claro...espero. lo cual no excluye la responsabilidad del autor. No porque sea un proyecto open source se te van a filtrar ranas por todos lados > 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" que claramente pueden llevar a problemas serios. Un solo ejemplo (inventado, apliquenlo a la situacion que se les ocurra): 1. /tmp con permisos ugo+w 2. Un servicio establece un socket para comunicacion con procesos ayudantes en el directorio tmp. 3. Un usuario "avanzado" se percata de la situacion, y se percata de que no hay sticky bit y procede a borrar el socket y cambiarlo por un nuevo socket adaptado a sus necesidades. 4. El "usuario avanzado" espera que uno de los procesos ayudantes se contacte con el socket y voila! Probablemente tomara unas 100 iteraciones dar con el momento exacto para borrar el socket y cambiarlo por otro, pero no es nada que un script y un par de cervezas no solucionen. Pregunta: Que pasa si el proceso que abrio el socket, era un proceso de autentificacion de usuarios? En cambio, el sticky bit existe para garantizar que esa situacion no se de. A no ser (y eso depende del sistema en cuestion, si utiliza sistemas mas avanzados como SELinux), que seas root con lo cual el sticky bit puede ser pasado a llevar. Esa clase de cosas, debiera ser revisada antes de que salga a la luz publica o de lo contrario mas de un dolor de cabeza te vas a llevar. A todo esto, no tengo ninguna intencion de criticar al mentado proyecto. Solo quiero resaltar que lo que parece una "pequennez" puede convertirse en la piedra angular de muchos problemas. Xhau -- http://toolchains.com/personal/blog
Problema X en debian
El Sab, 3 de Junio de 2006, 1:29 am, Horst von Brand escribió: > Juan MartÃnez <[EMAIL PROTECTED]> wrote: >> El vie, 02-06-2006 a las 10:54 -0400, [EMAIL PROTECTED] escribió: [...] >>> verifique que no hubiera problemas de espacio y estaba al 50% para la >>> raiz, >>> despues google y encontre que era un problemas de permisos de /tmp >>> drwxr-xr-x 13 root root 4096 Jun 2 10:42 tmp >>> los cambie con chmod ugo+w /tmp > >> Hubiera sido mas lindo con chmod 1777 /tmp :-) > > chmod a=rwx,+t /tmp # en castellano En gustos... >>> y listop pero la pregunta del millon es ¿quien cambio los permisos? > >> Mmm...a veces (en muy contadas veces) algunos paquetes pueden cometer >> estos cambios. Cosa rara, pero me han pasado cosas similares. Incluso >> las he reportado. > > Que pasen cosas como esas para mi seria razon suficiente para alejarme > rapidamente de los paquetes del caso, y seguramente buscar una > distribucion > menos irresponsable con la seguridad. Me extraña su respuesta Sr. profesor. Si nadie reporta este tipo de cosas, como hacer que avance el proyecto? Es una pequeñez esto que toco, pero precisamente aqui es donde va el caracter principal del software libre, en la colaboracion de la comunidad. Me imagino que Ud. lo tiene muy claro...espero. 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. -- Juan Martinez Depto. Inf. UMC
VPN PPTP e Iptables
> desde el kernel 2.6.14 la cosa ya esta soportado sin mayores parchados > aunque tuve algunos dramas ... > > con el 2.6.16 no tuve mayores problemas todo trabaja finisimo Al final compile el kernel 2.16.18, y me di cuenta que ahi mismo viene el soporte necesario. Si a alguien le sirve puedo dejar disponible el kernel y el .config. Saludos. morenisco.
