Resumo

  • A capability do Amoeba reunia uma porta de servidor de 48 bits, um número de objeto de 24, um mapa de direitos de 8 e um campo de verificação de 48: uma referência portadora de autoridade que processos de usuário podiam guardar e transmitir.
  • Quando o servidor aceitava o token, confirmava a regra de verificação e o direito pedido. Não confirmava o nome do portador, sua finalidade, seu mandato institucional, a conclusão de um efeito posterior nem sua persistência.

A ausência que definia o mecanismo

Um processo do Amoeba chegava ao servidor com uma sequência compacta de bits e uma operação. A porta encaminhava a solicitação ao serviço. O número do objeto escolhia um recurso dentro do espaço daquele servidor. Os bits de direitos delimitavam o que o portador podia pedir. O campo de verificação permitia identificar uma adulteração ou uma tentativa de ampliar privilégios.

Não havia campo para o nome de uma pessoa.

Essa ausência não era um cadastro de identidade deixado para uma versão futura. Ela fazia parte de uma arquitetura distribuída em que os próprios processos de usuário podiam manipular capabilities. A autoridade viajava na referência; o servidor validava a referência e a operação, não a biografia do apresentador. Assim, não era necessário que um componente central acompanhasse continuamente quem possuía cada capability.

O desenho respondia muito bem a uma pergunta limitada: o portador desta referência válida pode solicitar esta operação sobre este objeto deste servidor? Ele não respondia quem era o portador no organograma, por que decidiu agir, se um aprovador pretendia aquela ação ou se o mundo externo terminou no estado esperado.

Quatro campos com responsabilidades diferentes

O artigo de 1986 Using Sparse Capabilities in a Distributed Operating System fixa o formato: 48 bits para a porta do servidor, 24 para o número do objeto, 8 para os direitos e 48 para o campo de verificação. Ao todo, 128 bits.

A porta e o número do objeto não são duas metades do mesmo endereço. A porta identifica o ponto de serviço no modelo RPC do Amoeba. O número ganha significado dentro do servidor; o relatório de 1991 o compara, no caso de um servidor de arquivos, a um número de inode. O núcleo pode usar a porta para localizar o servidor, mas entrega a ele o restante da capability. Localização e interpretação do objeto ficam, portanto, separadas.

O byte de direitos também não é uma constituição universal de oito comandos. É um bitmap interpretado pela interface de cada servidor. Um arquivo pode oferecer leitura, escrita e remoção; um objeto de processo pode permitir iniciar, parar ou inspecionar. A largura comum não torna essas operações equivalentes. Ela oferece uma superfície pequena e explícita para declarar a autoridade do portador.

O campo de verificação protege essa declaração. Como um processo comum podia armazenar e copiar uma capability, o token não dependia de uma etiqueta secreta dentro do núcleo. O servidor guardava um segredo associado ao objeto e usava uma transformação de mão única para conferir se os valores visíveis de objeto e direitos combinavam com o campo apresentado. Alterar um bit de direito na memória não produzia automaticamente o campo de verificação correspondente.

Por isso, “referência infalsificável” precisa de contexto. A construção histórica buscava tornar a fabricação inviável sob suas premissas. Ela não transforma 48 bits em garantia eterna diante do poder computacional atual, não impede o uso de um token copiado de um portador legítimo e não cifra uma capability exposta em um canal inseguro. O próprio relatório de 1991 observa que a criptografia pode ser necessária para evitar divulgação acidental em um ambiente inseguro.

Atenuação significava retirar direitos

Uma capability de proprietário começava com todos os bits de direitos ativados. Para entregar menos autoridade a outro processo, o portador podia pedir ao servidor uma restrição por máscara. O servidor validava a capability original, calculava a interseção entre os direitos existentes e a máscara solicitada e criava, para o mesmo objeto, uma nova capability com menos direitos e um campo de verificação derivado. O exemplo std_restrict do guia de programação resume a operação: rights &= mask.

A direção é essencial. A máscara pode retirar autoridade; não pode acrescentar um direito ausente no token original. Se alguém mudar apenas o campo visível para reivindicar mais operações, a verificação deixa de coincidir e o servidor rejeita a capability. Atenuação era uma redução verificável, não uma cerimônia verbal de delegação.

Também é necessário preservar as diferenças entre as variantes estudadas. O texto de 1986 explora vários modos de proteger direitos: uma combinação de valor aleatório armazenado e direitos por função de mão única; uma emissão de capability restrita feita pelo servidor; e uma proposta de redução local com uma família de funções de mão única comutativas. O relatório de 1991 descreve o método assistido pelo servidor usado no relato daquela implementação. São experimentos relacionados, não um único algoritmo indistinto.

O limite de autoria merece o mesmo cuidado. Using Sparse Capabilities foi escrito por Andrew S. Tanenbaum, Sape J. Mullender e Robbert van Renesse. The Amoeba Distributed Operating System—A Status Report é de Tanenbaum, M. Frans Kaashoek, van Renesse e Henri E. Bal. Tanenbaum é uma porta de entrada humana legítima para a história; não é motivo para apagar o caráter coletivo do sistema.

Posse era autoridade, não identidade

O artigo de 1986 diz que um portador podia dar a outro processo uma cópia exata enviando a sequência de bits. Também registra que o sistema não precisava manter uma lista central de quem possuía quais capabilities. Essas propriedades davam portabilidade e transparência de localização, mas ao mesmo tempo delimitavam o que uma validação podia provar.

Uma verificação bem-sucedida mostra que o token apresentado é válido para aquele objeto e para os direitos visíveis sob o segredo atual do servidor. Ela não revela se o processo o recebeu do criador, o encontrou por meio de um diretório, o recebeu de outro processo ou o copiou de um lugar em que não deveria estar. Sem outro mecanismo, não há vínculo com um empregado, uma função contratual ou uma pessoa jurídica.

Validade tampouco prova finalidade. A mesma capability com escrita pode servir a uma manutenção rotineira, a uma recuperação de emergência ou a um experimento não autorizado. Os direitos limitam os verbos que o servidor aceita; não registram a justificativa empresarial para escolher um deles naquele momento.

A revogação tem fronteira semelhante. Mudar o valor aleatório guardado pelo servidor pode invalidar as capabilities existentes de um objeto. É um reset poderoso e amplo. Não é conhecimento seletivo de todas as cópias, atribuição retrospectiva do uso anterior nem prova de que a sequência vazada desapareceu de todos os processos e arquivos.

A resposta termina na borda semântica do servidor

Suponha que uma capability válida permita uma operação e que o servidor responda com sucesso. A afirmação mais forte é a definida por aquela operação: o servidor aceitou e executou a alteração segundo sua implementação. Isso não demonstra automaticamente que a mudança sobreviveu a uma falha, alcançou todas as réplicas, acionou um dispositivo físico, concluiu um pagamento externo ou cumpriu a política de mudança da organização.

São superfícies de controle diferentes. Persistência pertence ao limite de armazenamento e recuperação. Uma ação física ou de rede pertence ao subsistema que a executa e observa. A autorização humana pertence à instituição que estabelece o mandato. Um token compacto pode abrir uma operação sem se tornar recibo universal de tudo o que deveria acontecer depois.

A contribuição duradoura do exemplo do Amoeba está justamente em unir nomeação e proteção com clareza e então parar. Essa fronteira não é uma deficiência a esconder. É o que torna o mecanismo inteligível.

Fontes