Introducción

Una de las características que se echan en falta en los sistemas Linux actuales, especialmente en entornos corporativos, es la posibilidad de especificar los permisos de acceso a los ficheros con mayor granularidad. Los sistemas Linux siguen el modelo de permisos Unix tradicional segementando el tipo de acceso en tres categorías:

• El propietario del fichero (User)

• El grupo al que pertenece el fichero (Group)

• El resto de usuarios del sistema que no están en ninguna de las dos categorías anteriores (Other).

también conocido como modelo UGO (User, Group, Other).

Sin embargo, estas tres categorías se revelan insuficientes en una gran cantidad de situaciones, donde deseariamos poder especificar permisos diferenciados para varios usuarios o grupos determinados.

Aquí es donde entran en juego los permisos basados en Listas de Control de Acceso, más conocidos como ACLs. En este sistema de permisos los ficheros no tienen un juego fijo de permisos (como en el modelo tradicional, que tiene tres permisos y sólo tres), sino que los permisos del fichero son en realidad una lista de Entradas de Control de Acceso (o ACEs). Cada una de estas ACEs contiene un par (usuario/grupo, permiso) que indica un tipo de acceso determinado para un usuario o grupo, y el conjunto de todas ellas forman la ACL que marca el tipo de acceso permitido en un fichero.

Este sistema es el utilizado entre otros, por los sistemas de ficheros NTFS (de Windows NT y sucesores), el sistema UFS de Solaris y el sistema HFS de HP-UX.

ACLs en Linux

Hay un dato que se suele desconocer sin embargo y es que el sistema de ficheros ext2, desde su diseño original, previó la inclusión de este tipo de sistemas de control de acceso y estaban incluídos los enganches (hooks) necesarios para su implementación posterior, de forma 100% transparente y compatible hacia atrás.

Pues bien, desde hace varios años existen varios proyectos para incorporar los sistemas basados en ACL en los diferentes sistemas de ficheros soportados por Linux, y especialmente en ext2 (por ser el tipo de sistema de ficheros más extendido hasta el momento en los sistemas Linux).

Uno de ellos es el proyecto RSBAC, cuyos objetivos son mucho más ambiciosos (realmente mucho más, su objetivo es conseguir un sistema Linux con un nivel de seguridad equivalente al nivel B1 del antiguo Libro Naranja -TCSEC-), pero que incorpora también una implementación 100% operativa de ACLs para ext2.

Otro de ellos es el proyecto Linux Extended Attributes and Access Control Lists, que originalmente tenía como objetivo incorporar el sistema de ACLs al sistema de ficheros ext2 (y posteriormente ext3 cuando este apareció). Posteriormente, al ser el sistema de ACLs elegido por el equipo de Samba para su implementación de ACLs sobre ext2 (para poder ofertar recursos compartidos via SMB con ACLs al igual que los sistemas Windows NT y posteriores) ha sido el candidato oficial de ACLs en ext2 para su inclusión definitiva en el kernel. De hecho, desde la versión 2.5.23 forma parte del kernel estándar.

Para ello se ha hecho un esfuerzo de coordinación y estandarización bastante grande con los desarrolladores de otros sistemas de ficheros como XFS y JFS (principalmente, aunque no sólo con estos) que también soportaban ACLs desde su origen. La idea era ofertar una capa abstracta común en el VFS (Virtual File System) de forma que las aplicaciones y el resto del sistema operativo trabajasen por igual, y con la misma API, con cualquiera de los sistemas de ficheros que soportasen ACLs (ext2/ext3, XFS, JFS, ReiserFS, etc.).

El resultado: ya están disponibles los sistemas de ficheros con ACLs en el núcleo estándar, en su versión de desarrollo. Sin embargo, no es necesario esperar hasta la estabilización del actual núcleo de desarrollo para disfrutar de las ventajas de las ACLs. Todos los sistemas de ficheros mencionados arriba están disponibles bien como parte del kernel estándar, bien como parches, para las versiones estables del núcleo. Y son parches con calidad de producción, con lo cual son perfectamente utilizables en entornos cuya estabilidad sea una condición indispensable.

En el caso del sistema de ficheros ext2/ext3, que son el objetivo del proyecto Linux Extended Attributes and Access Control Lists, las ACLs son incluso transparentes para aquellos núcleos que no lleven incorporados los parches necesarios, de forma que si accidentalmente se arranca el sistema con un núcleo sin soporte para ACLs no ocurre absolutamente nada, salvo obviamente que no disponemos de las características avanzadas de las ACLs y sólo tenemos a nuestra disposición el modelo de permisos tradicional.

A condición de que tengamos un ejecutable de e2fsck que soporte ACLs, incluso si el núcleo no lo soporta, podemos ejecutar e2fsck sobre el sistema de ficheros de forma segura. En caso de tener un e2fsck sin soporte de ACLs, el único problema que tendremos en este caso es la pérdida de las ACLs, pero nunca la pérdida de datos.

Las versiones de e2fsprogs (el paquete donde se incluyen las utilidades de ext2) a partir de la version 1.28 ya incorporan soporte de serie para Atributos Extendidos (Extended Attributes o EAs), que es la característica del sistema de ficheros necesaria para poder implementar las ACLs. En el sitio del propio proyecto se pueden encontrar parches para algunas versiones anteriores de e2fsprogs, en caso de ser necesario.

Cómo incorporar ACLs a nuestro sistema Linux

¿Qué debemos hacer por tanto para disfrutar de ACLs en nuestros sistemas de ficheros ext2/ext3 ya mismo? Lo que sigue es un resumen de las instrucciones dadas en el propio sitio del proyecto, donde se indica paso a paso todo el proceso a seguir. Voy a presuponer en este caso que nuestro sistema no dispone de sistemas de ficheros con EAs y ACLs, con lo cual me voy a saltar los pasos de copia de respaldo de las ACLs actuales (y la limpieza del sistema).

1. Lo primero es obtener una copia de e2fsprogs que soporte EAs y ACLs. La version 1.28 o posterior servirá. En caso contrario, hay que obtener los parches mencionados arriba y las fuentes de nuestra version actual de e2fsprogs (seguramente nuestra distribución tendrá disponibles las fuentes en su repositorio habitual) y construir de nuevo los ejecutables e instalarlos en el sistema. Alternativamente podemos optar por instalar directamente una versión 1.28 o posterior directamente, sin parchear la actualmente usada en nuestra distribución.

2. A continuación debemos compilar un kernel con soporte para EAs y ACLs. Para ello debemos descargar los parches correspondientes a nuestro núcleo y aplicarlos de la siguiente forma (el directorio linux/ indica la ubicación donde tenemos desempaquetadas las fuentes del núcleo):

   $ cd linux/ $ zcat ../linux-a.b.c-xattr-x.y.z.diff.gz | patch -p1 $ zcat ../linux-a.b.c-acl-x.y.z.diff.gz | patch -p1

   Una vez parcheado es necesario incluir en la compilación las siguientes opciones al menos (disponibles en la categoria File Systems):

   CONFIG_FS_POSIX_ACL=y (POSIX Access Control Lists) CONFIG_EXT3_FS_XATTR=y (Ext3 extended attributes) CONFIG_EXT3_FS_POSIX_ACL=y (Ext3 POSIX Access Control Lists) CONFIG_EXT2_FS_XATTR=y (Ext2 extended attributes) CONFIG_EXT2_FS_POSIX_ACL=y (Ext2 POSIX Access Control Lists)

   Los nombres pueden variar ligeramente de una versión del kernel a otra. Las opciones xxx_XATTR son para activar los Atributos Extendidos, y las opciones xxx_POSIX_ACL para activar las ACLs. Los valores xxx_EXT2_xxx son para sistemas de ficheros ext2 y los valores xxx_EXT3_xxx para ext3.

   Existen otras dos opciones más (al menos en el kernel 2.4.19, que es el que estoy usando para escribir esto):

   1. Ext2 extended attribute block sharing (IG_EXT2_FS_XATTR_SHARING): que permite el uso de un mismo bloque común para almacenar los atributos extendidos de varios nodos-i, en el caso de que dichos atributos sean indénticos en todos los nodos-i.

   2. Ext2 extended user attributes (CONFIG_EXT2_FS_XATTR_USER): que permite a los procesos de usuario almacenar atributos extendidos adicionales en los nodos-i. Por ejemplo para almacenar cualquier tipo de información adicional que dichos procesos deseen, como el juego de caracteres usuado en el fichero (o cualquier otra cosa que se nos ocurra).

   Por supuesto, los dos valores anteriores existen de idéntica forma para el sistema de ficherox ext3.

3. El siguiente paso es construir las utilidades que sirven para gestionar los AEs y las ACLs de los ficheros: getfattr, setfattr, getfacl, setfacl, etc. Tenemos que descargar el paquete attr que es necesario para poder construir despues el paquete acl, que incluye las utilidades de gestión de las ACLs en sí (el paquete attr incluye además algunas utilidades de gestión de atributos extendidos).

   Es conveniente revisar primero si existen versiones ya empaquetas para nuestra distribución de Linux (tanto Debian GNU/Linux como RedHat, entre otras, las tienen), y que sea una versión de las mismas que sea compatible con la revisión del parche aplicada al núcleo que acabamos de construir

   En caso de no tenerlas en nuestra distribución, no ser compatibles o simplemente querer tener la última versión disponible compilada por nosotros mismos, estos son los pasos a seguir (necesitaremos el entorno de desarrollo autoconf y todas la utilidades de compilación/desarrollo habituales, más algún retoque manual):

   1. Desempaquetar las utilidades de gestión de Atributos Extendidos (attr-2.0.10.src.tar.gz en el momento de escribir esto):

      tar xzvf attr-2.0.10.src.tar.gz cd attr-2.0.10

      A continuación tenemos que compilar las herramientas en sí. Si nuestra distribución es RedHat o Debian GNU/Linux, las utilidades vienen con los ficheros de especificación y control necesarios para crear paquetes nativos (ver el fichero doc/INSTALL).

      En caso contrario, debemos compilar todo desde cero con las siguientes instrucciones (en el directorio raíz de los ficheros extraídos):

      autoconf ./configure make su root make install install-lib install-dev

      Este último método dejará todos los ejecutables más las bibliotecas de funciones de manejo de AEs bajo /usr/local. En general el fichero doc/INSTALL da las indicaciones necesarias para obtener los ejecutables en cualquiera de los casos (incluídas algunas indicaciones para deshabilitar el código de depuración, etc).

   2. Desempaquetar las utilidades de gestión de ACLs (acl-2.0.18.src.tar.gz en el momento de escribir esto):

      tar xzvf acl-2.0.18.src.tar.gz cd acl-2.0.18

      A continuación tenemos que compilar las herramientas en sí. Como en el caso anterior, si nuestra distribución tiene ya compiladas estas utilidades y con compatibles con la versión de los parches incluídos en el núcleo, lo más sencillo es usar los paquetes nativos de la distribución.

      En caso contrario, debemos compilar todo desde cero con las siguientes instrucciones (en el directorio raíz de los ficheros extraídos):

      autoconf ./configure make su root make install install-lib install-dev

      Este último método dejará todos los ejecutables más las bibliotecas de funciones de manejo de ACLs bajo /usr/local. Como en el caso anterior, el fichero doc/INSTALL da las indicaciones necesarias para obtener los ejecutables en cualquiera de los casos.

   3. Por último debemos obtener una versión del paquete fileutils parcheado para soportar EAs y ACLs. De lo contrario no podremos copiar los ficheros con sus AEs y ACLs, sacar en los listados la indicación de que hay acls adicionales a los permisos tradicionales (ya que se siguen manteniendo los permisos tradicionales), etc.

      En el propio sitio del proyecto se puede encontrar el parche para algunas versiones del paquete fileutils. En general esta es la parte más complicada del proceso, al ser un paquete completamente externo al sistema de ficheros y las utilidades ext2/ext3. Los problemas se presentarán si la versión de fileutils que vamos a utilizar no se corresponden exactamente a las indicadas en los parches, ya que tendremos que integrar parte de los cambios a mano, y eso siempre es más complicado.

Una vez compilado e instalado todo lo mencionado en los puntos anteriores ya tenemos todos los elementos necesarios para poder disfrutar de los EAs y las ACLs en nuestros sistemas de ficheros ext2/ext3. Sólo nos queda un último paso, indicar al núcleo que en un determinado sistema de ficheros deseamos usar ACLs (y EAs).

Para ello debemos editar el fichero /etc/fstab y añadir una opción adicional a la de aquellos sistemas de ficheros a los que queremos activar las ACLs : acl. También podemos añadir una opción para indicar explícitamente que no queremos usar las ACLs en un sistema de ficheros, aun si dicho sistema de ficheros contiene ACLs: noacl.

Existe un juego de opciones adicional para activar o desactivar el uso de los AEs de usuario (si hemos optado por compilarlos en nuestro núcleo): user_xattr y nouser_xattr. Por cierto, que los valores por defecto para todos los sistemas de ficheros ext2/ext3 en caso de no especificar nada son noacl y nouser_xattr

Una vez hecho lo anterior, sólo nos resta arrancar con el nuevo núcleo que acabamos de compilar y ¡voilá!, ya tenemos nuestras ACLs disponibles y listas para usar.