Gestión de permisos, usuarios y grupos – Introducción – III
Vamos profundizando en el tema.
Es recomendable leer las entregas anteriores, antes de continuar.
¿Cómo están definidos los permisos?
La primera vez parece algo realmente extraño si no se ha trabajado con él (es similar de permisos FTP, ya que éste proviene de Unix, y eran los más extendidos en la época en la que se elaboró el estándar del protocolo.)
Empezaremos con una versión muy simplificada de la realidad e iremos subiendo de complejidad.
Todo (incluidos los dispositivos) están representados como ficheros o directorios, y cada uno tiene su propietario, grupo y permisos.
Estructura de los permisos:
Directorio | Usuario Propietario | Grupo Propietario | Otros |
Donde:
d | Directorio |
l | Link / Enlace |
r | Read / Leer |
w | Write / Escribir |
x | Runnable / Ejecución |
Vamos con un ejemplo: listemos un directorio cualquiera para ver esta información (ignoremos de momento el resto):
Permisos | U.propietario | G.prop. | Tamaño | Fecha y hora | Nombre |
drwxr-xr-x | albireo | albireo | 4,0K | 07/05/09 18:08 | . |
drwxr-xr-x | albireo | albireo | 4,0K | 26/05/09 23:18 | .. |
drwxrwxr-x | albireo | eqengine | 4,0K | 07/05/09 18:08 | proyecto_app |
-rwxr-xr-x | albireo | albireo | 9,9K | 04/05/09 20:23 | quitasaltos |
-rw-r--r-- | albireo | albireo | 119 | 04/05/09 20:23 | quitasaltos.cpp |
lrwxrwxrwx | alcaudon | eqengine | 11 | 07/05/09 19:15 | zcodigo.cpp -> quitasaltos.cpp |
Aclaraciones:
. siempre designa al directorio actual, mientras que .. se refiere a su padre, el antecesor.
El propietario del directorio y del resto es albireo, y el grupo es también albireo, excepto para el directorio (tiene una d) proyecto_app, que aunque su usuario es albireo, el grupo es eqengine.
Forma alternativa de representar los permisos, es bastante útil aunque siempre podemos trabajar en función de r,w y x.
Tomando los en subgrupos de tres (usuario, grupo y otros), se aplica la siguiente codificación:
Y en otros grupos de tres (r,w y x): si se tiene ese permiso 1, sino 0.
-> al final tenemos un número en decimal que se corresponde.
111 CBA 000 | C(1)=4 B(1)=2 A(1)=1 C,B,A(0)=0 |
Tabla:
--- | 000 = 0 |
--x | 001 = 1 |
-w- | 010 = 2 |
-wx | 011 = 3 |
r-- | 100 = 4 |
r-x | 101 = 5 |
rw- | 110 = 6 |
rwx | 111 = 7 |
Nota importante: Con unos permisos de 000 (---/---/---) solamente root podrá acceder.
¿Cómo se aplican?
Muy simple, el sistema realiza los siguientes pasos:
- ¿Accede root? (SI) →Acceso completo, ignora los permisos.
- (NO), continúa ...
- ¿Accede el propietario? (SI) → Aplicamos los permisos del propietario.
- (NO), continúa …
- ¿Accede un miembro del grupo? (SI) → Aplicamos los permisos del grupo.
- (NO), continúa …
- Entonces, es “Otro” usuario -> Aplicamos los permisos para los “Otros”.
Artículos relacionados:
- Gestión de permisos, usuarios y grupos – Introducción – II
- Gestión de permisos, usuarios y grupos – Introducción – I
- SCP – II y Secure File Transfer Protocol (Protocolo de Transferencia Segura de Ficheros, SFTP)
- Asignar privilegios a usuarios o grupos con sudoers – I
- Introducción a la consola de GNU/Linux
8 jun 2009 a las 13:43
Hay que tener en cuenta que para que los permisos sean efectivos, el directorio en el que están los ficheros también tiene que tener los permisos perfectamente asignados.
Ejemplo típico: un archivo que tiene los siguientes permisos 000 (alguien dirá que lo puede proteger así ya que solo puede acceder root, y para eso hace falta una contraseña).
Pues bien si este fichero se encuentra en una ruta en la que el usuario del que queremos proteger nuestro fichero tienes permisos de lectura y escritura, si, correcto, este no podrá visualizar el contenido del fichero, pero podrá listarlo, eliminarlo o incluso moverlo y abrirlo con otro SO para así poder visualizarlo:
aabilio@debtoshi:~/Desktop$ touch hola
aabilio@debtoshi:~/Desktop$ chmod 000 hola
aabilio@debtoshi:~/Desktop$ ls -l hola
———- 1 aabilio aabilio 0 2009-06-08 13:40 hola
aabilio@debtoshi:~/Desktop$ mv hola hola2
aabilio@debtoshi:~/Desktop$ ls -l hola2
———- 1 aabilio aabilio 0 2009-06-08 13:40 hola2
aabilio@debtoshi:~/Desktop$ rm hola2
rm: remove write-protected fichero normal vacío “hola2″? y
aabilio@debtoshi:~/Desktop$ ls -l hola2
ls: cannot access hola2: No hay tal fichero o directorio
aabilio@debtoshi:~/Desktop$
(ejemplo con usuario normal en Desktop donde este tiene permisos de lectura y escritura)
“Nota importante: Con unos permisos de 000 (—/—/—) solamente root podrá acceder.”
Aquí se podría aclarar que algunos de los editores gráficos de texto si podrán abrir el fichero pero no podrán guardar posibles cambios (writer de open office si puede por ejemplo), pero si lo podrás editar y guardar con editores para terminal como vi o nano. Este es por ejemplo el caso de /etc/sudoers que en principio no se puede editar ni siquiera como root con gedit, por ejemplo, ya que no tiene permisos de escritura para nadie y te recomiendan abrirlo con visudo (ejecutar vi con con permisos de root, editor para terminal que si podrá guardar los cambios)
Los permisos tienen algunos entresijos interesantes…
8 jun 2009 a las 21:33
Buenas Aabilio,
Como ya comenté en la primera entrega: mi intención no era la de profundizar en todos los aspectos, sino dar una visión general que ayude a quién le interese a iniciarse.
Coincido contigo en que los permisos tienen entresijos interesantes, y se podría estar escribiendo de ellos toda la vida.
No era plan de empezar a hablar de los inodos y la estructura interna de POSIX (la verdad, no me importaría pero no me parece que fuera a despertar mucho interés) por lo que intento hacerlo más general y así llegar a más gente.
Ya he hablado de los permisos efectivos en otras ocasiones, y en la siguiente entrada de los atributos SUID, SGID y pegajoso.
Obviamente, en ningún momento he dicho que es 000 es la última línea de defensa.
Y siempre a menos que cifres el contenido del disco ( y empieza a ser discutible si existen vulnerabilidades ) puedes acceder a los ficheros, aunque sea en RAW.
La frase: “Nota importante: Con unos permisos de 000 (—/—/—) solamente root podrá acceder.”
Era un ejemplo, como introducción al siguiente punto.
Mientras el usuario tenga permisos en el directorio, podrá borrar ficheros de los que no posea permisos y/o no sea el propietario.
Por lo que borrar cualquier fichero es trivial si no están configurados adecuadamente los permisos para ese directorio o las restricciones heredadas.
Ya te puedes cansar de intentar hacer un rm -r directorio
si sobre este no tienes ninguna clase de permiso.
Respecto, al visudo su funcionalidad reside en prevenir la escritura simultánea del fichero. Realmente trabajas con el fichero y a la hora de guardar, cambia los permisos, guarda y los restaura.
De la misma forma puedes cambiarlo tú mismo, o bien mediante un script y usar el editor que prefieras.
De todas formas modificaré la entrada, para que no de lugar a dudas.
Gracias por revisarlo.
8 jun 2009 a las 22:45
Si no queda lugar a dudas en la entrada considero que está bien explicado (aunque se le puede complicar alguna parte a alguno no iniciado), simplemente era comentar algo más, por aquello de escribir un poco en algún lado ;)
No pasaba por aquí desde que esto era de Outime…
Saludos
8 jun 2009 a las 22:50
A por cierto, interesante lo de que visudo cambia los permisos en el momento de guardar (sabía que bloqueaba múltiples escrituras simultáneas y te avisaba de errores, pero desconocía ese punto).
11 sep 2009 a las 17:35
Queria saber si hay alguna forma de autorizar a un usuario a descargar actualizaciones pero no instalar nuevos programas.
Gracias.
25 may 2011 a las 0:25
Por supuesto ivan; Pon una camara en la habitación de ese usuario y si le pillas descargandose algun programa, entras y le metes una colleja, a partir de ese momento solo actualizara.
Espero que te sirva ;)
25 may 2011 a las 0:27
Pobre ivan, ya van 2 años sin que nadie le de una respuesta, que verguenza!!