Cuando ejecutas ls -l en cualquier directorio, lo que ves no es decoración: es el resumen completo del estado de un archivo desde el punto de vista del kernel. Esa línea aparentemente críptica como -rw-r--r-- 1 ana devs 4096 may 15 10:23 informe.txt contiene, en orden, el tipo de archivo, quién puede hacer qué con él, cuántas referencias existen en el sistema de archivos, quién lo posee, a qué grupo pertenece, cuánto ocupa, cuándo se tocó por última vez y cómo se llama. Vamos a desmontar cada pieza.
El modelo de permisos de Unix se basa en tres actores: el propietario (owner), el grupo y otros (other, es decir, cualquiera que no sea el propietario ni miembro del grupo). Para cada uno de esos tres actores, el sistema guarda tres bits: lectura (r), escritura (w) y ejecución (x). Si el bit no está activo, aparece un guion en su lugar. Esto significa que los nueve caracteres centrales de la primera columna no son texto libre: son literalmente tres grupos de tres bits almacenados en el inodo del archivo.
El primer carácter de esa columna es diferente: indica el tipo de archivo. Un guion (-) significa archivo regular. Una d es un directorio. Una l es un enlace simbólico. Una c es un dispositivo de caracteres (como un puerto serie) y una b es un dispositivo de bloques (como un disco). El kernel usa ese campo para saber cómo tratar el objeto; si lo ignoras y asumes que todo es un archivo regular, tarde o temprano romperás algo.
¿Por qué existe esta división en tres actores en lugar de una lista arbitraria de usuarios con permisos individuales? Porque en los setenta, con memoria y CPU escasas, un modelo de tres niveles era suficientemente expresivo para la mayoría de los casos de uso y costaba trivialmente poco de almacenar y evaluar. Las ACL (Access Control Lists) existen para casos más complejos, pero el modelo base sigue siendo estos nueve bits. Lo que sí falla cuando lo malinterpretas es predecible: si pones permisos demasiado abiertos, cualquier usuario del sistema puede leer tus archivos de configuración, que a menudo contienen contraseñas; si los pones demasiado restrictivos, procesos que necesitan acceder al archivo (como un servidor web) fallarán silenciosamente o con errores confusos de “permiso denegado”.
# Creamos un directorio de prueba para no tocar nada del sistema mkdir -p /tmp/demo_permisos cd /tmp/demo_permisos # Creamos tres archivos con diferentes perfiles de permisos echo "contenido del informe" > informe.txt echo "#!/bin/bash" > proceso.sh echo "usuario=admin" > config.conf # Asignamos los permisos más típicos que verás en producción: # 644 para archivos de datos/configuración (el propietario escribe, todos leen) chmod 644 informe.txt config.conf # 755 para scripts y ejecutables (el propietario ejecuta y escribe, todos ejecutan) chmod 755 proceso.sh # Creamos un directorio con permisos 700 (solo el propietario entra) mkdir privado chmod 700 privado # Creamos un enlace simbólico para ver el tipo 'l' ln -s informe.txt informe_link.txt # Ahora observamos todo junto ls -l # Salida esperada (el propietario será tu usuario actual): # -rw-r--r-- 1 ana ana 22 may 15 10:23 config.conf # -rw-r--r-- 1 ana ana 22 may 15 10:23 informe.txt # lrwxrwxrwx 1 ana ana 11 may 15 10:23 informe_link.txt -> informe.txt # drwx------ 2 ana ana 4096 may 15 10:23 privado # -rwxr-xr-x 1 ana ana 12 may 15 10:23 proceso.sh
Fíjate en lo que acaba de aparecer en pantalla. La línea de informe.txt empieza con -rw-r--r--: el primer carácter es -, archivo regular. Luego rw-: el propietario puede leer y escribir, pero no ejecutar (ese guion final es el bit de ejecución desactivado). Después r--: el grupo solo puede leer. Y otro r--: cualquier otro usuario del sistema también solo puede leer. Eso es exactamente lo que necesitas para un archivo de configuración: el administrador lo edita, el resto solo lo consulta.
La línea de proceso.sh muestra -rwxr-xr-x. El propietario tiene los tres bits: puede leer el script, modificarlo y ejecutarlo. El grupo y other tienen r-x: pueden leerlo y ejecutarlo, pero no modificar el script. Ese es el patrón correcto para un ejecutable compartido; si quitaras la x del grupo u other, esos usuarios obtendrían “permiso denegado” al intentar correrlo aunque puedan verlo en el listado.
El directorio privado aparece como drwx------. La d te confirma que es un directorio. rwx para el propietario: puede listar su contenido (r), crear o borrar archivos dentro (w) y entrar con cd (x). Los seis guiones significan que ni el grupo ni nadie más puede hacer absolutamente nada con ese directorio, ni siquiera saber qué hay dentro. Por eso Debian crea los directorios personales en /home con este modo: tu directorio ~/ es drwx------ por defecto. Si fuera drwxr-xr-x, cualquier usuario del sistema podría listar y leer tus archivos.
El enlace simbólico informe_link.txt empieza con l y muestra rwxrwxrwx. Esos nueve bits en un symlink no son los permisos que importan: el kernel los ignora y aplica los del archivo de destino. Lo relevante aquí es la l inicial y la flecha -> que te indica a dónde apunta.
El número 1 que aparece después de los permisos es el contador de hard links: cuántos nombres en el sistema de archivos apuntan al mismo inodo. Un archivo recién creado tiene uno. Los directorios suelen empezar en dos (el propio directorio y el . dentro de él). Después vienen el propietario y el grupo en texto, el tamaño en bytes, la fecha de última modificación y el nombre.
Una lectura rápida práctica: si el archivo empieza con -rw-r--r-- es un archivo de datos o configuración normal. Si empieza con -rwxr-xr-x es un ejecutable de uso general. Si ves drwx------ es un directorio privado. Con esos tres patrones identificas el noventa por ciento de lo que encontrarás en un sistema Debian en funcionamiento.
N° 34