Compartir vía

Listas de control de acceso (ACL) en Azure Data Lake Storage

  • Artículo

Azure Data Lake Storage implementa un modelo de control de acceso compatible con el control de acceso basado en rol (RBAC) de Azure y las listas de control de acceso (ACL) tipo POSIX. En este artículo se describen las listas de control de acceso de Data Lake Storage. Para aprender a incorporar el control de acceso basado en rol de Azure (RBAC) con las listas de control de acceso y cómo el sistema los evalúa para tomar decisiones relacionadas con la autorización, consulte Modelo de control de acceso en Azure Data Lake Storage.

Acerca de las listas de control de acceso

Puede asociar una entidad de seguridad a un nivel de acceso de archivos y directorios. Cada asociación se captura como una entrada en una lista de control de acceso (ACL) . Cada archivo y directorio de la cuenta de almacenamiento tiene una lista de control de acceso. Cuando una entidad de seguridad intenta realizar una operación en un archivo o directorio, una comprobación de ACL determina si esa entidad de seguridad (usuario, grupo, entidad de servicio o identidad administrada) tiene el nivel de permiso adecuado para llevarla a cabo.

Nota:

Las ACL se aplican solo a las entidades de seguridad del mismo inquilino. Las ACL no se aplican a los usuarios que usan la autorización de clave compartida porque no se puede realizar la autorización basada en permisos de la entidad de seguridad. Lo mismo sucede con los tokens de firma de acceso compartido (SAS), excepto cuando se usa un token de SAS delegado por el usuario. En ese caso, Azure Storage realiza una comprobación de ACL POSIX con el identificador de objeto antes de autorizar la operación siempre que se use el parámetro opcional suoid. Para obtener más información, consulte Construcción de una SAS de delegación de usuarios.

Establecimiento de las ACL

Para establecer permisos en el nivel de archivo y de directorio, consulte cualquiera de los siguientes artículos:

Entorno Artículo
Explorador de Azure Storage Uso del Explorador de Azure Storage para administrar listas de control de acceso en Azure Data Lake Storage
Azure portal Uso de Azure Portal para administrar ACL en Azure Data Lake Storage
.NET Uso de .NET para administrar listas de control de acceso (ACL) en Azure Data Lake Storage
Java Uso de Java para administrar listas de control de acceso (ACL) en Azure Data Lake Storage
Python Uso de Python para administrar listas de control de acceso (ACL) en Azure Data Lake Storage
JavaScript (Node.js) Uso de JavaScript SDK en Node.js para administrar ACL en Azure Data Lake Storage
PowerShell Uso de PowerShell para administrar listas de control de acceso en Azure Data Lake Storage
CLI de Azure Uso de la CLI de Azure para administrar listas de control de acceso (ACL) en Azure Data Lake Storage
REST API Ruta de acceso: Actualización

Importante

Si la entidad de seguridad es una entidad de servicio, es importante que utilice el identificador de objeto de la entidad de servicio en lugar del identificador de objeto del registro de aplicación relacionado. Para obtener el identificador de objeto de la entidad de servicio abra la CLI de Azure y, a continuación, use este comando: az ad sp show --id <Your App ID> --query objectId. No olvide reemplazar el marcador de posición <Your App ID> por el identificador de aplicación del registro de aplicaciones. La entidad de servicio se trata como un usuario con nombre. Agregará este identificador a la ACL como haría con cualquier usuario con nombre. Los usuarios con nombre se describen más adelante en este artículo.

Tipos de ACL

Hay dos tipos de listas de control de acceso: ACL de acceso y ACL predeterminadas.

las ACL de acceso controlan el acceso a un objeto. Tanto archivos como directorios tienen ACL de acceso.

Las ACL predeterminadas son plantillas de ACL asociadas con un directorio que determina las ACL de acceso de todos los elementos secundarios que se crean en ese directorio. Los archivos no tienen ACL predeterminadas.

Tanto las ACL de acceso como las ACL predeterminadas tienen la misma estructura.

Nota

El cambio de la ACL predeterminada en un elemento primario no afecta a la ACL de acceso o a la ACL predeterminada de los elementos secundarios que ya existen.

Niveles de permiso

Los permisos sobre directorios y archivos de un contenedor son Lectura, Escritura y Ejecución, y se pueden usar en archivos y directorios, como se muestra en la tabla siguiente:

Archivo Directorio
Lectura (R) Puede leer el contenido de un archivo Requiere permisos de lectura y ejecución para enumerar el contenido del directorio.
Escritura (W) Puede escribir o anexar a un archivo Requiere permisos de lectura y ejecución para crear elementos secundarios en un directorio.
Ejecución (X) No significa nada en el contexto de Data Lake Storage Se requiere para atravesar los elementos secundarios de un directorio.

Nota:

Si va a conceder permisos únicamente mediante listas de control de acceso (y no por medio de Azure RBAC), para conceder a una entidad de seguridad acceso de lectura o escritura a un archivo, necesitará otorgarle permisos de ejecución sobre la carpeta raíz del contenedor, y sobre cada carpeta de la jerarquía de carpetas que conduzcan al archivo.

Formas abreviadas de los permisos

RWX se usa para indicar Lectura + Escritura + Ejecución. Existe un formato numérico más condensado en el que Lectura = 4, Escritura = 2 y Ejecución = 1, y su suma representa los permisos. A continuación se muestran algunos ejemplos.

Formato numérico Formato abreviado Qué significa
7 RWX Lectura + Escritura + Ejecución
5 R-X Lectura + ejecución
4 R-- Lectura
0 --- Sin permisos

Herencia de permisos

En el modelo de estilo de POSIX usado por Data Lake Storage, los permisos de un elemento se almacenan en el propio elemento. En otras palabras, los permisos de un elemento no se pueden heredar de los elementos primarios si los permisos se establecen después de que ya se haya creado el elemento secundario. Los permisos solo se heredan si los permisos predeterminados se han establecido en los elementos primarios antes de crear los secundarios.

En la tabla siguiente se muestran las entradas de ACL necesarias para permitir que una entidad de seguridad realice las operaciones indicadas en la columna Operación.

En esta tabla se muestra una columna que representa cada nivel de una jerarquía de directorios ficticia. Hay una columna para el directorio raíz del contenedor (/), un subdirectorio denominado Oregón, un subdirectorio del directorio Oregón denominado Portland y un archivo de texto en el directorio Portland denominado Data.txt.

Importante

En esta tabla se supone que solo se usan listas de control de acceso sin asignaciones de roles de Azure. Para consultar una tabla similar que combina RBAC de Azure junto con las ACL, consulte Tabla de permisos: combinación de RBAC de Azure, ABAC y ACL.

Operación / Oregón/ Portland/ Data.txt
Leer Data.txt --X --X --X R--
Anexar a Data.txt --X --X --X RW-
Eliminar Data.txt --X --X -WX ---
Eliminar /Oregon/ -WX RWX RWX ---
Eliminar /Oregon/Portland/ --X -WX RWX ---
Crear o actualizar Data.txt --X --X -WX ---
Enumerar / R-X --- --- ---
Enumerar /Oregón/ --X R-X --- ---
Enumerar /Oregón/Portland/ --X --X R-X ---

Eliminar archivos y directorios

Como se muestra en la tabla anterior, para eliminar un archivo no es preciso tener permisos de escritura para él, siempre y cuando los permisos de directorio estén establecidos correctamente. Sin embargo, para eliminar un directorio y todo su contenido, el directorio primario debe tener permisos de escritura y ejecución. Tanto el directorio que se va a eliminar como todos los directorios que contiene requieren permisos de lectura, escritura y ejecución.

Nota:

El directorio raíz "/" nunca se puede eliminar.

Usuarios e identidades

Todos los archivos y directorios tienen permisos distintos para estas identidades:

  • El usuario propietario
  • El grupo propietario
  • Usuarios designados
  • Grupos designados
  • Entidades de servicio designadas
  • Identidades administradas designadas
  • Los restantes usuarios

Las identidades de usuarios y grupos son identidades de Microsoft Entra. Así que a menos que se indique lo contrario, un usuario, en el contexto de Data Lake Storage, puede referirse a un usuario de Microsoft Entra, entidad de servicio, identidad administrada o grupo de seguridad.

El superusuario

Un superusuario es el usuario con más derechos. Un superusuario:

  • Tiene permisos de lectura, escritura y ejecución (RWX) en todos los archivos y carpetas.

  • Puede cambiar los permisos de cualquier archivo o carpeta.

  • Puede cambiar el usuario propietario o el grupo propietario de cualquier archivo o carpeta.

Si un contenedor, archivo o directorio se crea con una clave compartida, una SAS de cuenta o una SAS de servicio, el propietario y el grupo propietario se establecen en $superuser.

El usuario propietario

El usuario que creó el elemento es automáticamente el usuario propietario del elemento. Un usuario propietario puede:

  • Cambiar los permisos de un archivo que le pertenece.
  • Cambiar el grupo propietario de un archivo que le pertenece, siempre que el usuario propietario también sea miembro del grupo de destino.

Nota

El usuario propietario no puede cambiar el usuario propietario de un archivo o directorio. Solo los superusuarios pueden cambiar el usuario propietario de un archivo o directorio.

El grupo propietario

En las ACL de POSIX, todos los usuarios están asociados a un grupo principal. Por ejemplo, el usuario "Alice" puede pertenecer al grupo "finance". Alice puede pertenecer a varios grupos, pero uno de ellos siempre se designa como su grupo principal. En POSIX, cuando Alice crea un archivo, el grupo propietario de ese archivo se establece en su grupo principal, que en este caso es "finance". De lo contrario, el grupo propietario se comporta de forma similar a los permisos asignados para otros usuarios o grupos.

Asignar el grupo propietario de un nuevo archivo o directorio

  • Caso 1: El directorio raíz /. Este directorio se crea cuando se crea un contenedor de Data Lake Storage. En este caso, el grupo propietario se establece en el usuario que creó el contenedor, en caso de que se haya realizado con OAuth. Si el contenedor se crea con una clave compartida, una SAS de cuenta o una SAS de servicio, el propietario y el grupo propietario se establecen en $superuser.
  • Caso 2 (cada dos casos): cuando se crea un elemento, se copia el grupo propietario del directorio primario.

Cambiar el grupo propietario

El grupo propietario se puede cambiar por:

  • Cualquier superusuario.
  • El usuario propietario, si el usuario propietario también es miembro del grupo de destino.

Nota

El grupo propietario no puede cambiar las ACL de un archivo o directorio. Aunque el grupo propietario se establece en el usuario que creó la cuenta en el caso del directorio raíz, Caso 1 anterior, una única cuenta de usuario no es válida para proporcionar los permisos mediante el grupo propietario. Puede asignar este permiso a un grupo de usuarios válidos si es aplicable.

Evaluación de los permisos

Las identidades se evalúan en el orden siguiente:

  1. Superusuario
  2. usuario propietario
  3. Usuario con nombre, entidad de servicio o identidad administrada
  4. Grupo propietario o grupo con nombre
  5. Los restantes usuarios

Si más de una de estas identidades se aplica a una entidad de seguridad, se concede el nivel de permiso asociado a la primera identidad. Por ejemplo, si una entidad de seguridad es el usuario propietario y un usuario con nombre, se aplica el nivel de permiso asociado al usuario propietario.

Todos los grupos con nombre se consideran juntos. Si una entidad de seguridad es miembro de más de un grupo con nombre, el sistema evalúa cada grupo hasta que se concede el permiso deseado. Si ninguno de los grupos con nombre proporciona el permiso deseado, el sistema pasa a evaluar una solicitud con respecto al permiso asociado a todos los demás usuarios.

El siguiente seudocódigo representa el algoritmo de comprobación de acceso de las cuentas de almacenamiento. Este algoritmo muestra el orden en el que se evalúan las identidades.

def access_check( user, desired_perms, path ) :
  # access_check returns true if user has the desired permissions on the path, false otherwise
  # user is the identity that wants to perform an operation on path
  # desired_perms is a simple integer with values from 0 to 7 ( R=4, W=2, X=1). User desires these permissions
  # path is the file or directory
  # Note: the "sticky bit" isn't illustrated in this algorithm

  # Handle super users.
  if (is_superuser(user)) :
    return True

  # Handle the owning user. Note that mask isn't used.
  entry = get_acl_entry( path, OWNER )
  if (user == entry.identity)
      return ( (desired_perms & entry.permissions) == desired_perms )

  # Handle the named users. Note that mask IS used.
  entries = get_acl_entries( path, NAMED_USER )
  for entry in entries:
      if (user == entry.identity ) :
          mask = get_mask( path )
          return ( (desired_perms & entry.permissions & mask) == desired_perms)

  # Handle named groups and owning group
  member_count = 0
  perms = 0
  entries = get_acl_entries( path, NAMED_GROUP | OWNING_GROUP )
  mask = get_mask( path )
  for entry in entries:
    if (user_is_member_of_group(user, entry.identity)) :
        if ((desired_perms & entry.permissions & mask) == desired_perms)
            return True

  # Handle other
  perms = get_perms_for_other(path)
  mask = get_mask( path )
  return ( (desired_perms & perms & mask ) == desired_perms)

La máscara

La máscara solo se aplica a la entrada ACL de un usuario con nombre, un grupo con nombre y el grupo propietario. La máscara especifica cuáles de los permisos de la entrada de ACL se usan para autorizar el acceso. Estos permisos aplicados se denominan permisos efectivos de la entrada de ACL. Se omiten todos los demás permisos de la entrada de ACL. Mediante el uso de la máscara, es posible establecer un límite superior en los niveles de permisos.

La máscara se puede especificar por cada llamada. Esto permite que diferentes sistemas de consumo, como los clústeres, tengan distintas máscaras eficaces para sus operaciones de archivo. Si se especifica una máscara en una solicitud dada, reemplaza completamente la máscara predeterminada.

El bit persistente

El bit persistente es una característica más avanzada de un contenedor POSIX. En el contexto de Data Lake Storage, es improbable que se necesite el bit persistente. En resumen, si el bit persistente está habilitado en un directorio, solo el usuario propietario del elemento secundario, el propietario del directorio o el superusuario ($superuser) pueden eliminarlo o cambiarle el nombre.

El bit persistente no se muestra en Azure Portal. Para obtener más información sobre el bit persistente y cómo establecerlo, consulte ¿Cuál es el bit persistente de Data Lake Storage?.

Permisos predeterminados del directorio raíz

En un nuevo contenedor de Data Lake Storage, el valor predeterminado de la ACL de acceso del directorio raíz ("/") es 750 para los directorios y 640 para los archivos. En la tabla siguiente se muestra la notación simbólica de estos niveles de permisos.

Entidad Directorios Archivos
usuario propietario rwx rw-
grupo propietario r-x r--
Otros --- ---

Los archivos no reciben el bit X, ya que no es pertinente para los archivos de un sistema de solo almacenamiento.

Permisos predeterminados en archivos y directorios nuevos

Cuando se crea un archivo o directorio en un directorio existente, la ACL predeterminada del directorio principal determina:

  • Una ACL de acceso y una ACL predeterminada del directorio secundario.
  • Una ACL de acceso de un archivo secundario (los archivos no tienen ninguna ACL predeterminada).

umask

Al crear una ACL predeterminada, se aplica umask a la ACL de acceso para determinar los permisos iniciales de una ACL predeterminada. Si se define una ACL predeterminada en el directorio primario, umask se omite de forma eficaz y la ACL predeterminada del directorio primario se usa para definir estos valores iniciales en su lugar.

umask es un valor de 9 bits en los directorios principales que contiene un valor RWX para usuario propietario, grupo propietario y otro.

El valor de umask para Azure Data Lake Storage es una constante establecida en 007. Este valor se convierte en:

componente umask Formato numérico Formato abreviado Significado
umask.owning_user 0 --- En el caso del usuario propietario, copie la ACL de acceso del elemento principal en la ACL predeterminada del elemento secundario.
umask.owning_group 0 --- En el caso del grupo propietario, copie la ACL de acceso del elemento principal en la ACL predeterminada del elemento secundario.
umask.other 7 RWX En el caso de otro, quite todos los permisos en la ACL de acceso del elemento secundario.

Preguntas más frecuentes

¿Es preciso habilitar la compatibilidad con las ACL?

No. El control de acceso mediante ACL se habilita para una cuenta de almacenamiento siempre que el espacio de nombres jerárquico esté ACTIVADO.

Si el espacio de nombres jerárquico está DESACTIVADO, las reglas de autorización de RBAC siguen siendo aplicables.

¿Cuál es la mejor manera de aplicar las ACL?

Use siempre grupos de seguridad de Microsoft Entra como entidad de seguridad asignada en una entrada de ACL. Ofrece la oportunidad de asignar directamente usuarios individuales o entidades de servicio. Con esta estructura, podrá agregar y quitar usuarios o entidades de servicio sin necesidad de volver a aplicar las ACL en una estructura de directorios completa. En su lugar, solo puede agregar o quitar usuarios y entidades de servicio del grupo de seguridad de Microsoft Entra adecuado.

Hay muchas maneras diferentes de configurar grupos. Por ejemplo, Imagine que tiene un directorio denominado /LogData que contiene los datos de registro generados por su servidor. Azure Data Factory (ADF) ingiere los datos en esa carpeta. Usuarios concretos del equipo de ingeniería de servicios cargarán los registros y administrarán a otros usuarios de esta carpeta y varios clústeres de Databricks de archivos analizarán los registros de esa carpeta.

Para habilitar estas actividades, puede crear un grupo LogsWriter y un grupo LogsReader. Luego, puede asignar permisos como se indica a continuación:

  • Agregue el grupo LogsWriter a la lista de control de acceso del directorio /LogData con permisos de rwx.
  • Agregue el grupo LogsReader a la lista de control de acceso del directorio /LogData con permisos de r-x.
  • Agregue el objeto de entidad de servicio o Managed Service Identity (MSI) para ADF al grupo LogsWriters.
  • Agregue los usuarios del equipo de ingeniería de servicios al grupo LogsWriter.
  • Agregue el objeto de entidad de servicio o MSI para Databricks al grupo LogsReader.

Si un usuario del equipo de ingeniería de servicios deja la empresa, puede quitarle del grupo LogsWriter. Si no agregó dicho usuario a un grupo, sino que en su lugar agregó una entrada de ACL dedicada para ese usuario, tendrá que quitar esa entrada del directorio /LogData. También tendría que quitar la entrada de todos los subdirectorios y archivos de toda la jerarquía de directorios del directorio /LogData.

Para crear un grupo y agregar miembros, vea Crear un grupo básico y agregar miembros mediante Microsoft Entra ID.

Importante

Azure Data Lake Storage Gen2 depende de Microsoft Entra ID para administrar los grupos de seguridad. Microsoft Entra ID recomienda limitar a menos de 200 el número de miembros de un grupo para una entidad de seguridad determinada. Esta recomendación se debe a una limitación de los JSON Web Tokens (JWT) que proporcionan la información de pertenencia a grupos de una entidad de seguridad principal dentro de las aplicaciones Microsoft Entra. Si se superase este límite, se podrían producir problemas de rendimiento inesperados con Data Lake Storage Gen2. Para obtener más información, vea Configurar notificaciones de grupo para aplicaciones mediante Microsoft Entra ID.

¿Cómo se evalúan los permisos de RBAC de Azure y ACL?

Para obtener información sobre cómo el sistema evalúa las listas de control de acceso y los roles RBAC de Azure en conjunto para tomar decisiones relacionadas con la autorización para los recursos de cuentas de almacenamiento, consulte Evaluación de los permisos.

¿Cuáles son los límites de las asignaciones de roles de Azure y las entradas de ACL?

En la tabla siguiente se proporciona una vista resumida de los límites que se deben tener en cuenta al usar RBAC de Azure para administrar los permisos "generales" (permisos que se aplican a las cuentas de almacenamiento o los contenedores) y usar ACL para administrar permisos "específicos" (permisos que se aplican a archivos y directorios). Use grupos de seguridad para las asignaciones de ACL. Mediante el uso de los grupos, es menos probable que supere el número máximo de asignaciones de roles por suscripción y el número máximo de entradas de ACL por archivo o directorio.

Mechanism Ámbito Límites Nivel de permiso admitido
Azure RBAC Cuentas de almacenamiento, contenedores.
Asignaciones de roles de Azure entre recursos en el nivel de suscripción o de grupo de recursos.		 4000 asignaciones de roles de Azure en una suscripción Roles de Azure (integrados o personalizados)
ACL Directorio, archivo 32 entradas de ACL (realmente 28 entradas de ACL) por archivo y por directorio. Las ACL de acceso y predeterminadas tienen su propio límite de 32 entradas de ACL. Permiso de ACL

¿Admite Data Lake Storage la herencia de RBAC de Azure?

Las asignaciones de roles de Azure se heredan. Las asignaciones fluyen desde la suscripción, el grupo de recursos y los recursos de la cuenta de almacenamiento hasta el recurso del contenedor.

¿Admite Data Lake Storage la herencia de ACL?

Las ACL predeterminadas pueden usarse para establecer las ACL de nuevos subdirectorios y archivos secundarios creados en el directorio principal. Para actualizar las ACL de los elementos secundarios existentes, debe agregar, actualizar o quitar las ACL de forma recursiva para la jerarquía de directorios deseada. Para obtener instrucciones, consulte la sección Establecimiento de las ACL de este artículo.

¿Qué permisos son necesarios para eliminar de forma recursiva un directorio y su contenido?

  • El autor de la llamada tiene permisos de "superusuario",

Or

  • El directorio principal debe tener permisos de escritura y ejecución.
  • Tanto el directorio que se va a eliminar como todos los directorios que contiene requieren permisos de lectura, escritura y ejecución.

Nota

No necesita permisos de escritura para eliminar archivos en directorios. Además, el directorio raíz "/" nunca se puede eliminar.

¿Quién es el propietario de un archivo o directorio?

El creador de un archivo o directorio se convierte en el propietario. En el caso del directorio raíz, esta es la identidad del usuario que creó el contenedor.

¿Qué grupo se establece como grupo propietario de un archivo o directorio al crearlo?

El grupo propietario se copia del directorio primario en la que se crea el archivo o directorio.

Soy el usuario propietario de un archivo, pero no tengo los permisos de RWX que necesito. ¿Qué puedo hacer?

El usuario propietario puede cambiar los permisos del archivo y concederse los permisos de RWX que necesite.

¿Por qué a veces veo GUID en ACL?

Se muestra un GUID si la entrada representa a un usuario y ese usuario ya no existe en Microsoft Entra. Normalmente esto ocurre cuando el usuario ha dejado la empresa o si su cuenta ha sido eliminada en Microsoft Entra ID. Además, las entidades de servicio y los grupos de seguridad no tienen un nombre principal de usuario (UPN) para identificarlos y, por tanto, se representan mediante su atributo OID (un GUID). Para limpiar las ACL, elimine manualmente estas entradas de GUID.

¿Cómo configuro las ACL correctamente para una entidad de servicio?

Cuando defina las ACL para entidades de servicio, es importante que utilice el identificador de objeto (OID) de la entidad de servicio para el registro de aplicación que creó. Es importante tener en cuenta que las aplicaciones registradas tienen una entidad de servicio independiente en el inquilino específico de Microsoft Entra. Las aplicaciones registradas tienen un OID que es visible en Azure Portal, pero la entidad de servicio tiene otro OID diferente. Artículo: para obtener el OID de la entidad de servicio que corresponde a un registro de aplicación, puede usar el comando az ad sp show. Especifique el identificador de aplicación como parámetro. Este es un ejemplo de cómo obtener el OID de la entidad de servicio que se corresponde a un registro de aplicación con el identificador de aplicación = 00001111-aaaa-2222-bbbb-3333cccc4444. Ejecute el siguiente comando en la CLI de Azure:

az ad sp show --id 00001111-aaaa-2222-bbbb-3333cccc4444 --query objectId

Se mostrará OID.

Cuando tenga el OID correcto de la entidad de servicio, vaya a la página Administrar acceso del Explorador de Azure Storage para agregar el OID y asignar los permisos adecuados para este. No olvide seleccionar Guardar.

¿Se puede establecer la ACL de un contenedor?

No. Un contenedor no tiene una ACL. Pero puede establecer la ACL del directorio raíz del contenedor. Cada contenedor tiene un directorio raíz, que comparte el mismo nombre que el contenedor. Por ejemplo, si el nombre del contenedor es my-container, el del directorio raíz será my-container/.

La API REST de Azure Storage contiene una operación denominada Set Container ACL (Establecer ACL del contenedor), pero esa operación no se puede usar para establecer la ACL de un contenedor ni del directorio raíz de un contenedor; En su lugar, esa operación se usa para indicar si se puede acceder a los blobs de un contenedor con una solicitud anónima. Se recomienda requerir autorización para todas las solicitudes a los datos de blobs. Para obtener más información, vea Información general: Corrección del acceso de lectura anónimo para los datos de blobs.

¿Dónde puedo obtener más información sobre el modelo de control de acceso POSIX?

Consulte también