Autorización de acceso de lista de control de acceso

Editar en línea

El propietario del recurso de información es responsable de gestionar los derechos de acceso. Los recursos están protegidos por bits de permiso, que se incluyen en la modalidad del objeto.

Para la ACL AIXC , los bits de permiso definen los permisos de acceso otorgados al propietario del objeto, al grupo del objeto y a la clase predeterminada others . El tipo de ACL AIXC da soporte a tres modalidades diferentes de acceso (lectura, escritura y ejecución) que se pueden otorgar por separado.

Cuando un usuario inicia sesión en una cuenta (utilizando el mandato login o su ), los ID de usuario y los ID de grupo asignados a dicha cuenta se asocian a los procesos del usuario. Estos ID determinan los derechos de acceso del proceso.

Para archivos, directorios, tuberías con nombre y dispositivos (archivos especiales) con una ACL AIX® asociada, el acceso se autoriza de la siguiente manera:

Para cada entrada de control de acceso (ACE) de la lista de controles de acceso (ACL), la lista de identificadores se compara con los identificadores del proceso. Si hay una coincidencia, el proceso recibe los permisos y restricciones definidos para esa entrada. Las uniones lógicas para ambos permisos y restricciones se calculan para cada entrada coincidente en la ACL. Si el proceso solicitante no coincide con ninguna de las entradas de la ACL, recibe los permisos y restricciones de la entrada predeterminada.
Si la modalidad de acceso solicitada está permitida (incluida en la unión de los permisos) y no está restringida (incluida en la unión de las restricciones), se otorga el acceso. De lo contrario, se rechaza el acceso.

Además, para un tipo de ACL de AIXC , la lista de identificadores de una ACL coincide con un proceso si todos los identificadores de la lista coinciden con el tipo correspondiente de identificador efectivo para el proceso solicitante. Un identificador de tipo USER coincidente equivale al ID de usuario en vigor del proceso y un identificador de tipo GROUP es coincidente si es igual al ID de grupo en vigor del proceso o de uno de los ID de grupo complementario. Por ejemplo, una ACE con una lista de identificadores como la siguiente:

USER:fred, GROUP:philosophers, GROUP:software_programmer

coincidiría con un proceso con un ID de usuario efectivo de fred y un conjunto de grupos de:

philosophers, philanthropists, software_programmer, doc_design

pero no coincidiría con un proceso con un ID de usuario efectivo de fred y un conjunto de grupos de:

philosophers, iconoclasts, hardware_developer, graphic_design

Tenga en cuenta que una ACE con una lista de identificadores de lo siguiente coincidiría con ambos procesos:

USER:fred, GROUP:philosophers

En otras palabras, la lista de identificadores de las funciones ACE es un conjunto de condiciones que deben contener para que se otorgue el acceso especificado.

El mecanismo de control de acceso discrecional permite un control de acceso efectivo de los recursos de información y proporciona una protección separada de la confidencialidad e integridad de la información. Los mecanismos de control de acceso controlado por el propietario sólo son tan efectivos como los hacen los usuarios. Todos los usuarios deben comprender cómo se otorgan y se deniegan los permisos de acceso y cómo se establecen.

Tenga en cuenta que para los objetos del sistema de archivos que tienen asociado un tipo de ACL NFS4, las comprobaciones de acceso se basan en varias ACE que forman la ACL así como en la configuración de normas del RFC relacionado con el protocolo NFS versión 4. La comprobación de la identidad se realiza comparando el ID de usuario o el ID de grupo o las series who especiales definidas en la ACE con las credenciales del proceso. Si se produce una coincidencia, los derechos de acceso solicitados se comparan con los derechos de acceso definidos en la ACE. Si alguno de los derechos de acceso está permitido, se tomarán estos y la operación de comparación continuará con la siguiente ACE. Este proceso continúa hasta que se alcanza el final de la ACL o hasta que se cumplen todos los derechos de acceso o hasta que se deniega alguno de los derechos de acceso solicitado. Los pasos siguientes capturan la comprobación de acceso en el caso de un objeto del sistema de archivos que tiene asociada una ACL NFS4:

Para cada entrada de control de acceso (ACE) de la lista de controles de acceso (ACL), la lista de identificadores se compara con los identificadores del proceso. Las comprobaciones de identidad incluyen el ID de usuario o el ID de grupo definido en la ACE. Además, si la identidad se define como special con series como OWNER@, se producirá una coincidencia si el proceso de llamada es por el propietario del archivo. Si existe una coincidencia, el proceso recibe los derechos de acceso definidos para dicha entrada. De lo contrario, continúe con la ACE siguiente.
Los derechos de acceso solicitados se comparan con los derechos de acceso recuperados de la entrada ACE. Si la ACE deniega explícitamente alguno de los derechos de acceso solicitados, se finaliza el proceso de comprobación de acceso y se deniega el acceso al proceso solicitante.
Si la ACE cumple alguno de los derechos de acceso solicitados, se tomarán dichos derechos de acceso de la lista de derechos de acceso de solicitud y la operación de comparación continuará con la siguiente ACE.
Si las ACE cumplen todos los derechos de acceso solicitados, se permite el acceso solicitado.
Si se alcanza el final de la ACL antes de resolver todos los derechos de acceso solicitados, el acceso se deniega.

Observe que aparte de las comprobaciones de acceso basadas en el tipo de ACL, los sistemas de archivos físicos individuales también pueden optar por proporcionar un acceso basado en el privilegio para los objetos del sistema de archivos. Por ejemplo, un propietario puede tener siempre permiso para modificar la ACL independientemente de los derechos de acceso de ACL existentes. Un proceso con un ID de usuario 0 se conoce como proceso de usuario root. Estos procesos generalmente tienen todos los permisos de acceso autorizados. Pero si un proceso de usuario root solicita permiso de ejecución para un programa, el acceso sólo se concede si se ha otorgado permiso de ejecución a, como mínimo, un usuario.

Todas las comprobaciones de permisos de acceso para estos objetos se realizan en el nivel de llamada al sistema cuando se accede al objeto por primera vez. Debido a que se accede a los objetos de System V Interprocess Communication (SVIPC) de forma independiente, se realizan comprobaciones para cada acceso. Sin embargo, es posible que las comprobaciones las realicen los sistemas de archivos físicos en el tiempo de apertura del objeto del sistema de archivos y no en el tiempo de operación de lectura o grabación. Para objetos con nombres de sistema de archivos, es necesario poder resolver el nombre del objeto real. Los nombres se resuelven de forma relativa (en el directorio de trabajo del proceso) o de forma absoluta (en el directorio raíz del proceso). La resolución de los nombres empieza con la búsqueda de uno de éstos.