En la versión 8.0 y releases anteriores de ClearCase, cada elemento de la base de objetos con versión (VOB) tiene tres categorías de protección: propietario (owner), grupo (group) y otros (other). Para cada categoría, el administrador puede establecer o borrar los bits de lectura y ejecución. Por ejemplo, si tiene un archivo fuente que debe ser legible para el propietario y los miembros del grupo del elemento, pero no a todos los usuarios de la red, debe establecer owner=read, group=read, other=none. Si tiene un archivo ejecutable para una determinada herramienta de programación, puede definir los tres tipos para leer y ejecutar.
A efectos prácticos, este modelo requiere la utilización de un grupo distinto para cada clase de elemento que comparte la misma protección. Si no permite que todos los usuarios lean elementos en su VOB, debe establecer other=none y controlar el acceso con las categorías de grupo (group) y propietario (owner).
El elemento owner tiene solo una utilidad limitada en la protección de los elementos, dejando únicamente a group con método de control efectivo. El elemento owner se establece de forma predeterminada en la cuenta de usuario que ha creado el elemento. Si tiene varios desarrolladores, los propietarios de los elementos variarán, lo que no es conveniente como método de control de acceso. Algunos administradores configuran un desencadenante para cambiar la propiedad de la cuenta del propietario VOB después de la creación del elemento, pero este método tampoco es conveniente como control de acceso puesto que la mayoría de los usuarios con frecuencia asumen la identidad del propietario VOB.
Esto deja al grupo del elemento como el mecanismo para controlar el acceso a cada elemento. El administrador debe definir un grupo separado para cada clase de elemento que se debe proteger. Por ejemplo, el elemento clase 1 es para los desarrolladores del componente A. El elemento clase 2 es para los desarrolladores del componente B. El elemento clase 3 es para todos los desarrolladores (código compartido). Si tiene 25 componentes (A-Y) y un componente compartido (Z), necesitará 26 grupos para controlar el acceso. Debería proteger todos los elementos en el componente A como de lectura para el grupo A, pero no legibles para el resto. Procedería de la misma manera para los componentes B-Y. Cada desarrollador del componente A-Y sería un miembro de dicho grupo, y también un miembro del grupo Z. La cuenta utilizada para compilar e integrar todo el código necesitaría ser miembro de todos los grupos A-Z.
Los grupos que ClearCase utiliza los define el sistema operativo (dominio Windows, UNIX NIS o LDAP) y se añaden a las credenciales del usuario cuando la cuenta inicia una sesión en el host en el que se ejecuta ClearCase. Desafortunadamente, debido a limitaciones en los protocolos de red utilizados en el sistema operativo y en ClearCase, un único usuario puede utilizar 16 grupos (UNIX y Linux) o 32 grupos (Windows) a la vez con ClearCase. En el ejemplo anterior, la cuenta de compilación/integración necesita utilizar 26 grupos para completar la compilación. Por lo tanto, se necesitaría una secuencia más compleja de pasos de compilación y cambios en las credenciales definiendo qué grupos se activan para ClearCase o comprometer la implementación de la seguridad del elemento utilizando menos grupos/clases de elemento. Ninguna de estas opciones es deseable.
Si se habilitan las listas de control de acceso (ACL) para proteger los elementos en una VOB con el nivel de característica 8 en ClearCase 8.0.1, podrá cambiar la estrategia de control de acceso para eliminar muchos situaciones en las que se alcanzarían los límites de pertenencia de grupos por usuario. Las listas de control de acceso (ACL) permiten colocar elementos en varios grupos en lugar de tener que colocar usuarios en varios grupos. Puesto que el número de grupos que se permiten en una lista de control de acceso (ACL) efectiva no está limitada con los mismos límites reducidos del número de grupos para una cuenta de usuario, este mecanismo de seguridad permite un nuevo tipo de protección y simplifica otros tipos.
Con listas de control de acceso (ACL) en elementos, puede otorgar el acceso a varios usuarios individuales, varios grupos y algunas categorías "everyone". Este tema trata sobre las listas de control de acceso (ACL) en elementos en términos de sus listas de control de acceso (ACL) efectivas. En este tema, y en otros relacionados, hay ejemplos sobre cómo las políticas y las correlaciones de roles se combinan para generar listas de control de acceso (ACL) efectivas.
En el ejemplo anterior, había 25 componentes A-Y, a los que se accedía a través de un equipo diferente y a través de una cuenta de compilación ("builders"), y a la que nadie más debía acceder. Con las listas de control de acceso (ACL), protegería cada elemento en un componente dado con una lista de control de acceso (ACL) efectiva compartida que otorgaría permisos de cambio a groupA y a builders.
Todos los otros componentes B-Y tendrían listas de control de acceso (ACL) efectivas similares. El componente Z (el componente compartido) también tendría una lista de control de acceso (ACL) efectiva similar. En esta configuración, cada cuenta de los miembros del equipo está en el correspondiente grupo para su componente, más el grupo para Z (como anteriormente). La cuenta builder sólo necesita estar en el grupo "builders". No alcanzará los límites en relación a la pertenencia a grupos simultáneos para la cuenta builder.
Tampoco tendrá que utilizar estrategias complejas durante una compilación del sistema ni comprometer la seguridad de los componentes A-Y. También obtendrá la flexibilidad necesaria para añadir grupos adicionales y acceso de solo lectura a los elementos. Suponga que el componente Z es mantenido por su propio grupo y que los equipos A-Y deben hacer referencia al mismo. Colocaría los desarrolladores que no son del equipo Z en el grupo "alldevelopers" en lugar de colocarlos en "groupZ". Puede configurar la lista de control de acceso (ACL) del elemento del componente Z de forma que groupZ tenga permisos de cambiar, alldevelopers tengan permisos de lectura y que buliders tengan permisos de cambiar.
Un desarrollador en el equipo A podrá leer los elementos en el componente Z pero no los podrá modificar. (Sin las listas de control de acceso, esto hubiera precisado de una extracción previa de operación y un desencandenante mkbranch para comprobar el permiso para modificar el elemento, y rechazar la operación si no estuviese autorizada).
También puede colocar cuentas individuales en listas de control de acceso de elemento. Esto puede tener sentido si hay un algunas personas que necesitan acceso específico a un componente, en el caso en el que no valga la pena crear un nuevo grupo de sistema operativo solo para esta finalidad. De forma que si el equipo del componente B tuviese que modificar el componente B, más otro usuario adicional ("extrauser"), la lista de control de acceso (ACL) otorgaría permisos a groupB, a extrauser y a builders.
Si tiene varios componentes que son mantenidos por varios equipos, podría incluso eliminar algunos grupos utilizados con anterioridad. Suponga que el componente E esta siendo mantenido por todos los miembros de los equipos para los componentes C y D. En el ejemplo de la versión 8.0, necesitaría un grupo E para contener todos los miembros tanto del grupo C como el D. Con las listas de control de acceso (ACL), podría configurar la lista de control de acceso (ACL) para el componente E para indicar ambos grupos y, a continuación, abandonar la utilización del grupo E (eliminarlo de la lista de grupos para las cuentas en los equipos C y D).
La descripción anterior hablaba en términos de listas de control de acceso (ACL) efectivas. En una VOB, la lista de control de acceso efectiva (ACL) se genera aplicando una correlación de roles a una política. La base de datos de VOB calcula y coloca en memoria caché la lista de control de acceso (ACL) efectiva para cada correlación de roles. Cada elemento se asocia con una correlación de roles. Para implementar los ejemplos anteriores, necesitará una correlación de roles diferente para cada clase de elemento (componentes A - Z). Puede enlazar todas estas correlaciones de roles a una única política que describa su modelo general de protección. Más abajo encontrará una política de ejemplo y un conjunto de correlaciones de roles que tienen como resultado unas listas de control de acceso (ACL) efectivas mostradas con anterioridad. (En la práctica, probablemente querrá añadir un grupo o usuario administrativo para tener un control completo sobre todos los elementos).