Esta entrada es más una anécdota que una descripción técnica. Para quienes se interesen en conocer más, hay mucha información al respecto en libros, artículos y páginas web pero, a fin de comprender lo que aquí se relata, es necesario una introducción.

El sistema de seguridad básico del file system de Unix es bastante simple, y bueno. Escribo básico, porque a su alrededor se han agregado muchas extensiones para «granularizar» el nivel de control sobre los objetos  (lo que puede entenderse como «archivos» en general) del file system. Principalmente, estas adiciones son representadas por las listas de control de acceso (ACL, por sus siglas en inglés), y los atributos extendidos (desplegables con el switch -@ en el formato largo el comando ls). Aunque pueden haber también esquemas adicionales que cada sistema operativo derivado de las grandes familias de Unix implementa junto con productos desarrollados ex profeso.

Ciertamente estas adiciones brindan un nivel de protección extra que ayuda cuando hay excepciones a la rigidez del modelo básico, pero también es cierto que llega a complicar la actividad de manipulación de archivos. Llegándola a convertir en algo exasperante para la mayoría.

Personal y profesionalmente han sido contadas las ocasiones en las que he requerido un ACL o hacer uso de algún atributo extendido. Tales ocasiones han sido cuando alguien sale con tener que hacer «algo especial» (como el no ser dueño del archivo ni pertenecer al grupo del dueño y ser miembro de otros grupos a los que no se les puede dar el mismo nivel de acceso requerido). Fuera de esto, encuentro los permisos básicos más que suficientes.

Muchos encuentran esto de los atributos extendidos y los ACLs complicado y molesto y prefieren no usarlos. Muchos de éstos son quienes tampoco entienden el esquema básico de permisos y quienes terminan dando un «777» a todo para no tener que lidiar con limitaciones. Muchas veces, incluso, productos o desarrollos se instalan con root por estas mismas razones. Una mala práctica, definitivamente. Adicionalmente, existe un bit de protección adicional en el esquema básico, que se establece con el octeto adicional de mayor magnitud, es decir «1777», «2777» y así.

Ahora, la anécdota. Cuando laboraba para Banamex (sí, ese nido de malas prácticas y problemas), sucedió algo que sólo puede ser explicable por la ignorancia que relato dos párrafos atrás. Empleábamos el web server iPlanet (ya obsoleto y declarado inseguro desde hacía ya tiempo atrás). En la estructura de directorios un área de caché debía poseer el modo «1777», lo que permitía que los procesos asociados al web server pudieran generar los objetos que necesitasen en este caché sin el riesgo de que otros procesos o usuario los borraran.

Las políticas del banco establecían que todos los sistemas Unix debían ser diseñados teniendo en mente que las estructuras de directorios poseyeran permisos «755» o «750», según fuera el caso, para que sólo el usuario con el que se instalaba la aplicación pudiera borrar los archivos. Basta señalar que iPlanet se instalaba con root, por lo que un «755» o «750» difícilmente permitiría a alguien fuera de un grupo administrativo hacer algo. Sin embargo, el modo «1777» funcionaba muy bien para el caché. Las mencionadas políticas de seguridad nos obligaban a cambiar los permisos como ya se ha mencionado, pese a que el fabricante del producto señalaba los permisos que cada directorio debería tener. Ni las explicaciones técnica ni las indicaciones del fabricante sirvieron. Un «750» se aplicó a toda la estructura del iPlanet, por supuesto la bitácora de los web servers estaba llena de mensajes señalando que el caché no era utilizable y errores al respecto. El equipo usaba tiempo escribiendo estos mensaje de error además de tener que destinar recursos a recrear objetos que podían tomarse del caché. Resultado: el portal Banamex por mucho tiempo figuró entre los sitios web bancarios con el menor rendimiento.