Manual de FreeBSD
Anterior | Capítulo 3. Conceptos básicos de Unix | Siguiente

# 3.3. Permisos

FreeBSD, cuya raíz histórica es el UNIX® BSD, se fundamenta en varios conceptos clave de UNIX. El primero y más importante es que FreeBSD es un sistema operativo multi-usuario. El sistema puede gestionar múltiples usuarios trabajando simultáneamente y en tareas que no guarden relación entre sí. El sistema se encarga de compartir y administrar peticiones de dispositivos de hardware, periféricos, memoria y tiempo de CPU de manera equitativa para cada usuario.

Debido a que el sistema es capaz de soportar múltiples usuarios, todo lo que el sistema administra tiene un conjunto de permisos que usa para decidir quién puede leer, escribir y ejecutar un recurso. Estos permisos se guardan como octetos divididos en tres partes: una para el propietario del fichero, otra para el grupo al que el fichero pertenece, y otra para todos los demás grupos y usuarios. Veamos una representación numérica de esto:

Valor | Permiso | Listado de directorio
--- | --- | ---
0 | No leer, no escribir, no ejecutar | `---`
1 | No leer, no escribir, ejecutar | `--x`
2 | No leer, escribir, no ejecutar | `-w-`
3 | No leer, escribir, ejecutar | `-wx`
4 | Leer, no escribir, no ejecutar | `r--`
5 | Leer, no escribir, ejecutar | `r-x`
6 | Leer, escribir, no ejecutar | `rw-`
7 | Leer, escribir, ejecutar | `rwx`

Puede utilizar el parámetro de línea de órdenes `-l` de ls(1) para ver un listado largo que incluya una columna con información acerca de los permisos de fichero para el propietario, grupo y los demás. Por ejemplo, un `ls -l` en un directorio puede mostrar algo como esto:

    % ls -l
    total 530
    -rw-r--r--  1 root  wheel     512 Sep  5 12:31 mifichero
    -rw-r--r--  1 root  wheel     512 Sep  5 12:31 otrofichero
    -rw-r--r--  1 root  wheel    7680 Sep  5 12:31 email.txt
    ...

Aquí está como se divide la primera columna de `ls -l`:

    -rw-r--r--

El primer caracter (más a la izquierda) indica si este fichero es un fichero regular, un directorio, un dispositivo especial de caracter, un socket o cualquier otro dispositivo especial pseudo-ficheroa . En este caso, el `-` un fichero regular. Los siguientes tres caracteres, `rw-` en este ejemplo, dan los permisos para el propietario del fichero. Los siguientes tres caracteres, `r--`, dan los permisos para el grupo al que el fichero pertenece. Los últimos tres caracteres, `r--`, dan los permisos para el resto del mundo. Un guión indica que el permiso está desactivado. En el caso de este fichero, los permisos están asignados de tal manera que el propietario puede leer y escribir en el fichero, el grupo puede leer el fichero, y el resto del mundo sólo puede leer el fichero. De acuerdo con la tabla de arriba, los permisos para este fichero serían `644`, donde cada dígito representa las tres partes de los permisos del fichero.

Todo ésto está muy bien, pero ¿cómo controla el sistema los permisos de los dispositivos? FreeBSD en realidad trata la mayoría de los dispositivos hardware como un fichero que los programas pueden abrir, leer y en los que pueden escribir datos como si de cualquier otro fichero se tratara. Estos ficheros especiales de dispositivo se encuentran en el directorio `/dev`.

Los directorios también son tratados como ficheros. Tienen permisos de lectura, escritura y ejecución. El bit de ejecución en un directorio tiene un significado ligeramente distinto que para los ficheros. Cuando un directorio está marcado como ejecutable significa que se puede mirar dentro, se puede hacer un «cd» (cambiar directorio) a él. Esto también significa que dentro del directorio es posible acceder a ficheros cuyos nombres son conocidos (sujeto, claro está, a los permisos de los ficheros mismos).

En particular, para poder realizar un listado de directorio, el permiso de lectura debe ser activado en el directorio, mientras que para borrar un fichero del que se conoce el nombre es necesario tener permisos de escritura y ejecución en el directorio que contiene el fichero.

Existen más permisos, pero se usan principalmente en circunstancias especiales como los binarios ejecutables de tipo setuid y los los directorios de tipo «sticky». Si desea más información acerca de los permisos de ficheros y cómo establecerlos, consulte chmod(1).

## 3.3.1. Permisos simbólicos

Escrito por Tom Rhodes.

Los permisos simbólicos, también conocidos como expresiones simbólicas, utilizan caracteres en lugar de valores octales para asignar permisos a ficheros o directorios. Las expresiones simbólicas utilizan la sintaxis de (quién) (acción) (permisos) mediante los siguientes valores:

Opción | Letra | Representa
--- | --- | ---
(quién) | u | Usuario
(quién) | g | Grupo propietario
(quién) | o | Otro
(quién) | a | Todos («todo el mundo»)
(acción) | + | Añadir permisos
(acción) | - | Quitar permisos
(acción) | = | Activar permisos explícitamente
(permisos) | r | Lectura
(permisos) | w | Escritura
(permisos) | x | Ejecución
(permisos) | t | Bit Sticky («pegajoso»)
(permisos) | s | Activar UID o GID

Estos valores se aplican con chmod(1) de la misma manera que los anteriores, pero con letras. Por ejemplo, podría usar la siguiente orden para bloquear a otros usuarios el acceso a `FICHERO`:

    % chmod go= FICHERO

Puede usarse una lista separada por comas cuando se quiera aplicar más de un conjunto de cambios a un fichero. Por ejemplo la siguiente orden eliminará los permisos de escritura de grupo y «mundo» a `FICHERO`, y añade permisos de ejecución para todos:

    % chmod go-w,a+x FILE

## 3.3.2. Banderas de fichero en FreeBSD

Escrito por Tom Rhodes.

Además de los permisos de fichero previamente expuestos, FreeBSD permite el uso de «banderas de fichero». Estas banderas añaden un nivel de seguridad y control adicional a los ficheros, pero no a los directorios.

Las banderas de fichero añaden un nivel adicional de control sobre los ficheros ayudando a asegurar que en algunos casos ni siquiera `root` pueda eliminar o alterar ficheros.

Las banderas de fichero se modifican mediante chflags(1), gracias a una interfaz muy sencilla. Por ejemplo, para habilitar la bandera imborrable de sistema en `fichero1`, escriba lo siguiente:

    # chflags sunlink fichero1

Y para dehabilitar la bandera imborrable de sistema, simplemente escriba la orden previa con «no» antes de `sunlink`. Observe:

    # chflags nosunlink fichero1

Para ver las banderas de este fichero, utilice ls(1) con las opciones `-lo`:

    # ls -lo fichero1

La salida debería ser como esta:

    -rw-r--r--  1 trhodes  trhodes  sunlnk 0 Mar  1 05:54 fichero1

Varias banderas solo pueden ser añadidas o retiradas de ficheros por el usuario `root`. En otros casos, el propietario del fichero puede activar estas banderas. Se recomienda que para más información la persona encargada de la administración del sistema consulte las páginas de manual chflags(1) y chflags(2).

## 3.3.3. Los permisos `setuid`, `setgid` y `sticky`

Escrito por Tom Rhodes.

Además de los permisos que se han explicado hay más, hay tres tipos más que todos los administradores deberían conocer. Son los permisos `setuid`, `setgid` y `sticky`.

Estos permisos juegan un papel clave en ciertas operaciones UNIX puesto que facilitan funcionalidades que no se suelen permitir a los usuarios normales. Para comprenderlas totalmente hay que comprender la diferencia entre el ID real del usuario y el ID efectivo.

El ID del usuario real es el UID que arranca (y el propietario) del proceso. El UID efectivo es el ID bajo el que se ejecuta el proceso. Veamos un ejemplo; el programa passwd(1) se ejecuta con el ID real del usuario puesto que el usuario está cambiando su contraseña. Pero para poder manipular la base de datos de contraseñas debe ejecutarse con el ID efectivo del usuario `root`. De este modo es posible que los usuarios cambien su contraseña sin llegar a ver un error de `Permission Denied` (permiso denegado).

> Nota: La opción `nosuid` de mount(8) hace que estos binarios den errores silenciosos, es decir, fallarán pero el usuario no recibirá ningún mensaje de error por ello. Esta opción no funciona siempre, pues, según la página man de mount(8), un «wrapper» `nosuid` puede sortear esta limitación.

El permiso setuid puede asignarse colocando un número cuatro (4) antes de los permisos. Se ve mejor con un ejemplo:

    # chmod 4755 ejemplosuid.sh

Los permisos de ``ejemplosuid.sh`` deberían ser así:

    -rwsr-xr-x   1 trhodes  trhodes    63 Aug 29 06:36 ejemplosuid.sh

Fíjese atentamente en la `s` que ha aparecido en los permisos del fichero, en la parte de los permisos del propietario; esa `s` está en donde estaría el bit de ejecución. Gracias a esto el funcionamiento de aplicaciones que necesitan permisos elevados, como `passwd`, pueden funcionar.

Si quiere ver un ejemplo con sus propios ojos abra dos terminales. En una arranque un proceso (ejecute) `passwd` con un usuario normal. Mientras la aplicación espera a que le de una nueva contraseña busque la información de usuario del proceso `passwd` en la tabla de procesos.

En la terminal A:

    Changing local password for trhodes
    Old Password:

En la terminal B:

    # ps aux | grep passwd

    trhodes  5232  0.0  0.2  3420  1608   0  R+    2:10AM   0:00.00 grep passwd
    root     5211  0.0  0.2  3620  1724   2  I+    2:09AM   0:00.01 passwd

Tal y como se ha dicho, un usuario normal puede ejecutar `passwd`, pero en realidad está utilizando el UID efectivo de `root`.

El permiso `setgid` actúa del mismo modo que el `setuid`, pero afecta a los permisos del grupo. Cuando una aplicación funciona con esta configuración lo hace con los permisos del grupo al que pertenece el fichero, no los del usuario que ha arrancado el proceso.

Si quiere utilizar el permiso `setgid` debe situar un núnmero dos (2) al principio de los permisos que vaya a asignar mediante `chmod`.

    # chmod 2755 ejemplosuid.sh

La nueva configuración tiene un aspecto muy similar a la que tenía antes, pero observe que la `s` de antes está ahora en el campo de los permisos de grupo:

    -rwxr-sr-x   1 trhodes  trhodes    44 Aug 31 01:49 ejemplosuid.sh

> Nota: En ambos ejemplos, incluso si el «script» en cuestión es ejecutable, no se va a ejecutar con un EUID distinto o un ID efectivo de usuario porque los «scripts» de shell no pueden acceder a la llama del sistema setuid(2).

Los dos permisos que acabamos de mostrar los bits de permisos (`setuid` y `setgid`) pueden reducir el nivel de seguridad haciendo que se escalen los permisos. Pero hay un tercer bit especial de permisos que puede ser de mucha ayuda para reforzar la seguridad del sistema: el `sticky bit`.

El `sticky bit`( que podríamos traducir como «bit pegajoso») aplicado a un directorio hace que solamente el propietario de un fichero pueda borrarlo. Esto evita el borrado de ficheros ajenos en directorios públicos como `/tmp`. Si quiere usarlo coloque un uno (1) antes de los permisos. Veamos un ejemplo:

    # chmod 1777 /tmp

Para ver el `;sticky bit` en acción usamos `ls`:

    # ls -al / | grep tmp

    drwxrwxrwt  10 root  wheel         512 Aug 31 01:49 tmp

El `sticky bit` es la letra `t` al final de los permisos.

Anterior | Inicio | Siguiente
Consolas virtuales y terminales | Subir | Estructura de directorios

Puede descargar éste y muchos otros documentos desde ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

Si tiene dudas sobre FreeBSD consulte la documentación antes de escribir a la lista <questions@FreeBSD.org>.
Envíe sus preguntas sobre la documentación a <doc@FreeBSD.org>.