Problema X en debian

[Carlos Manuel Duclos Vergara]

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