Na versão 8.0 e liberações anteriores do ClearCase, cada elemento VOB tem três categorias de proteção: proprietário, grupo e outro. Para cada categoria, o administrador pode configurar ou limpar os bits de leitura e execução. Por exemplo, se você tem um arquivo de origem que deve ser legível para o proprietário e os membros do grupo de elementos, mas não para todos os usuários na rede, então você deve configurar owner=read, group=read, other=none. Se você tem um arquivo executável para alguma ferramenta de programação, você pode configurar todos os três para leitura e execução.
Em termos práticos, esse modelo requer que você use um grupo separado para cada classe de elementos que compartilhar a mesma proteção. Se você não permitir que todos os usuários leiam elementos em seu VOB, então deve configurar other=none e controlar o acesso usando as categorias de proprietário e grupo.
O proprietário do elemento tem utilidade somente limitada na proteção do elemento, deixando somente o grupo como um controle efetivo. O proprietário de um elemento é, por padrão, configurado para a conta do usuário que criou o elemento. Se você tiver diversos desenvolvedores, então os proprietários do elemento irão variar, o que não é conveniente para controle de acesso. Alguns administradores configuram um acionador para mudar a propriedade para a conta do proprietário do VOB após a criação do elemento, mas isso também é inconveniente para controle de acesso, pois a maioria dos usuários raramente assume a identidade do proprietário do VOB.
Isso deixa o grupo do elemento como o mecanismo para controlar acesso para cada elemento. O administrador deve definir um grupo separado para cada classe de elemento que precisa de proteção. Por exemplo, a classe de elemento 1 é para desenvolvedores de componente A. A classe de elemento 2 é para desenvolvedores de componente B. A classe de elemento 3 é para todos os desenvolvedores (código compartilhado). Se você tiver 25 componentes (A-Y) e um componente compartilhado (Z), você precisa de 26 grupos para controlar o acesso. Você protegeria todos os elementos no componente A como legíveis para o grupo A, mas não legíveis para os outros. Da mesma forma para os componentes B-Y. Cada desenvolvedor de componente A-Y seria um membro desse grupo, e também um membro do grupo Z. A conta usada para construir e integrar todo o código precisa ser um membro de todos os grupos A-Z.
Os grupos usados pelo ClearCase são definidos pelo sistema operacional (Domínio do Windows, UNIX NIS ou LDAP) e incluídos nas credenciais de um usuário quando ele efetuar login em um host que execute ClearCase. Infelizmente, devido a limitações nos protocolos de rede usados no sistema operacional e no ClearCase, um único usuário pode usar somente 16 grupos (UNIX e Linux) ou 32 grupos (Windows) ao mesmo tempo com o ClearCase. No exemplo acima, a conta de construção/integração precisa usar 26 grupos para concluir a construção - a necessidade de algum sequenciamento complexo de etapas de construção e mudanças de credenciais ao definir quais grupos são ativados para o ClearCase ou comprometer a implementação da segurança do seu elemento e usar menos classes/grupos de elementos. Nenhuma das opções é desejável.
Se você ativar as ACLs para proteção de elementos em um VOB de Nível de Recurso 8 no ClearCase 8.0.1, é possível mudar a sua estratégia de controle de acesso para eliminar muitos casos nos quais você atinge os limites de associação ao grupo por usuário. Isso pode ajudar a pensar nas ACLs da seguintes maneira: elas permitem que você coloque elementos em diversos grupos em vez de ter de colocar usuários em diversos grupos. Como o número de grupos permitidos na ACL efetiva de um elemento não é limitado aos mesmos limites baixos do número de grupos para uma conta de usuário, esse mecanismo de segurança possibilita alguns novos casos de uso e simplifica outros.
Com as ACLs nos elementos, é possível conceder acesso a diversos usuários individuais, diversos grupos e algumas poucas categorias de "todos". Esse tópico discute as ACLs em elementos em termos de suas ACLs efetivas. Nesse e em tópicos relacionados há exemplos de como os mapas de funções e políticas se combinam para gerar ACLs efetivas.
No exemplo acima, havia 25 componentes A-Y, cada um deles para ser acessado por uma equipe e por uma conta de construção ("construtores") diferentes, mas ninguém mais deve ter acesso. Com as ACLs, você protegeria cada elemento em um determinado componente com uma ACL efetiva compartilhada que concederia permissões de mudança para o grupo A e para os construtores.
Cada um dos outros componentes B-Y teria uma ACL efetiva similar. O componente Z (o componente compartilhado) também teria uma ACL efetiva similar. Nessa configuração, a conta de cada membro da equipe está no grupo correspondente para seu componente, mais o grupo para Z (como antes). Mas a conta do construtor precisa somente estar no grupo de "construtores". Você não incorre em limites na associação ao grupo simultânea para a conta do construtor.
Você também não precisa usar estratégias complexas durante a construção de um sistema nem comprometer a segurança para os componentes A-Y. Você também ganha flexibilidade para incluir grupos adicionais e acesso somente leitura aos elementos. Suponha que o componente Z é mantido por sua própria equipe, mas deve ser referenciado apenas pelas equipes A-Y e você coloca os não desenvolvedores de Z no grupo "todos os desenvolvedores" em vez de no "grupo Z". É possível configurar a ACL do elemento Z do componente para que "grupo Z" tenha permissões de Mudança, "todos os desenvolvedores" tenha permissões de Leitura e "construtores" tenha permissões de Mudança.
Um desenvolvedor na equipe A poderá ler elementos no componente Z, mas não modificá-los. (Sem as ACLs, isso iria requerer uma verificação de pré-operação e o acionador mkbranch para verificar a permissão para modificar o elemento, e rejeitar uma operação se não autorizada.)
Também é possível colocar contas individuais em ACLs do elemento. Isso pode fazer sentido se houver poucos indivíduos que precisem de acesso específico a um componente, em um caso no qual não valha a pena criar um novo grupo de sistema operacional apenas para esse propósito. Assim, se o componente B deve ser modificável por sua equipe, mais outro usuário ("usuário extra"), a ACL concederia permissões de Mudança para grupo B, usuário extra e construtores.
Se você tiver alguns componentes que são mantidos por diversas equipes, você pode até conseguir eliminar alguns grupos usados anteriormente. Suponha que o componente E foi mantido por todos os membros da equipe para os componentes C e D. No exemplo 8.0, você precisou do grupo E para conter todos os membros de ambos os grupos C e D. Com as ACLs, é possível configurar a ACL para o componente E para nomear ambos os grupos, depois abandonar o uso do grupo E (removê-lo da lista de grupos para contas nas equipes C e D).
A descrição prévia se refere em termos de ACLs efetivas. Em um VOB, a ACL efetiva é gerada pela aplicação de um mapa de funções em uma política. O banco de dados do VOB calcula e armazena em cache a ACL efetiva para cada mapa de funções. Cada elemento é associado a um mapa de funções. Para implementar os exemplos acima, você precisará de um mapa de funções distinto para cada classe de elementos (componentes A - Z). É possível vincular todos esses mapas de funções em uma única política que descreva o seu modelo de proteção geral. Abaixo está uma política e conjunto de mapas de funções de exemplo que produzem as ACLs efetivas mostradas acima. (Na prática, você provavelmente deseja incluir um usuário ou grupo administrativo para ter controle Total sobre todos os elementos.)