Résumé

  • La capability d’Amoeba associait un port serveur de 48 bits, un numéro d’objet de 24 bits, huit bits de droits et un champ de contrôle de 48 bits : une référence porteuse de droits, directement manipulable par les processus utilisateurs.
  • Sa validation établissait la conformité du jeton et la présence du droit demandé. Elle n’établissait ni l’identité humaine du porteur, ni son mandat, ni la finalité de la demande, ni l’achèvement ou la persistance d’une conséquence extérieure.

Une autorité sans annuaire des porteurs

Le modèle est plus facile à comprendre en partant de ce qu’il n’exigeait pas. Un processus n’avait pas à être retrouvé dans un annuaire mondial avant chaque opération. Il présentait une capability au serveur. Le port conduisait au service ; le numéro désignait un objet dans l’espace propre à ce service ; les droits bornaient les verbes acceptables ; le champ de contrôle permettait au serveur de repérer une falsification.

La capability ne comportait aucun nom de personne. Cette absence correspondait à l’ambition distribuée d’Amoeba. Les programmes utilisateurs pouvaient conserver et transmettre les références, alors que le serveur restait l’autorité d’interprétation de ses objets. Le contrôle portait sur le jeton et l’opération, non sur une identité civile ou une fonction dans l’entreprise.

Ce choix ne signifie pas que l’identité est inutile. Il signifie seulement qu’elle n’est pas prouvée par ce mécanisme. Confondre les deux transforme une preuve technique étroite en mandat imaginaire : « le jeton est valable » devient « cette personne était autorisée à vouloir ce résultat ». Amoeba ne fait pas cette promesse.

Une construction de 128 bits, pas une métaphore

L’article de 1986 Using Sparse Capabilities in a Distributed Operating System détaille quatre champs. Le port serveur occupe 48 bits, le numéro d’objet 24, les droits 8 et le champ de contrôle 48. Le rapport d’étape de 1991 précise la répartition des tâches : le noyau exploite le port pour localiser le service, tandis que le serveur reçoit les autres informations et interprète le numéro d’objet. Dans un serveur de fichiers, ce numéro peut jouer un rôle comparable à celui d’un inode UNIX.

Le champ des droits est un bitmap, mais ses huit positions n’ont pas une signification universelle. Un serveur de fichiers peut y attacher lecture, écriture ou suppression ; un serveur de processus, démarrage, arrêt ou inspection. La capability transporte donc une autorité définie par l’interface de l’objet, pas une liste abstraite de pouvoirs valable partout.

Le champ de contrôle protège cette association. Le serveur conserve une valeur aléatoire liée à l’objet et vérifie une transformation à sens unique combinant cette valeur et les droits. Modifier les bits de droits sans pouvoir produire le contrôle correspondant rend la capability invalide. Le dispositif permet ainsi de laisser les jetons en mémoire utilisateur sans faire confiance à chaque détenteur pour les conserver intacts.

Il faut néanmoins borner le mot « infalsifiable ». La conception historique cherchait à rendre la fabrication impraticable dans son environnement. Elle ne certifie pas la solidité contemporaine d’un champ de 48 bits et ne protège pas contre la copie complète d’un jeton valable. Le rapport de 1991 observe d’ailleurs qu’un environnement non sûr peut exiger du chiffrement pour éviter la divulgation accidentelle des capabilities.

Restreindre voulait dire enlever

À la création d’un objet, l’owner capability activait tous les droits. Pour transmettre une autorité moindre, son détenteur pouvait demander au serveur une version restreinte. Le serveur validait la capability d’origine, intersectait les droits existants avec un masque, conservait le même objet et calculait un nouveau champ de contrôle. Dans le guide de programmation, le cœur de std_restrict tient dans l’opération rights &= mask.

Le sens de l’opération est essentiel. Elle retranche des droits ; elle n’en crée pas. Un porteur ne peut pas rallumer un bit absent et espérer que le contrôle reste valable. Le serveur détecte l’incohérence.

Les sources décrivent toutefois plusieurs variantes qu’il ne faut pas fusionner. L’article de 1986 examine le calcul d’un contrôle à partir d’une valeur aléatoire et des droits, la réémission par le serveur d’une capability réduite, puis une construction fondée sur plusieurs fonctions à sens unique commutatives permettant une atténuation locale. Le rapport de 1991 expose le chemin avec intervention du serveur. Ces propositions partagent une idée, mais ne constituent pas un unique algorithme déployé.

La pluralité concerne aussi les auteurs. Le texte de 1986 est signé Andrew S. Tanenbaum, Sape J. Mullender et Robbert van Renesse. Le rapport de 1991 est signé Tanenbaum, M. Frans Kaashoek, van Renesse et Henri E. Bal. Amoeba est un travail collectif ; le nom de Tanenbaum ouvre l’histoire sans absorber ceux des coauteurs.

Un jeton accepté n’identifie pas son parcours

Une capability pouvait être dupliquée en copiant ses bits. L’article de 1986 souligne qu’aucun registre central ne devait nécessairement indiquer qui détenait quoi. C’était une source de simplicité et de transparence de localisation. C’était aussi une limite probatoire.

Une vérification réussie montre que la capability est valable, pour cet objet et ces droits, relativement au secret actuel du serveur. Elle ne révèle pas si le processus l’a reçue du créateur, d’un répertoire, d’un autre processus ou d’une fuite. Une autre couche doit relier l’exécution à une identité ou à un rôle lorsque cette attribution est requise.

Le jeton n’encode pas davantage l’intention. Une même autorité d’écriture peut servir à la maintenance prévue, à la reprise d’urgence ou à une modification non approuvée. Le serveur sait quels verbes il accepte, pas quelle justification organisationnelle accompagne leur emploi.

Même la révocation est délimitée. Modifier la valeur aléatoire conservée par le serveur peut invalider toutes les anciennes capabilities de l’objet. Cela réinitialise l’autorité sur l’objet ; cela ne localise pas chaque copie, n’attribue pas les usages antérieurs et n’efface pas les archives qui contiennent le vieux bit pattern.

Le succès s’arrête à la sémantique du serveur

Après validation, une réponse positive prouve le résultat défini par l’opération du serveur. Elle ne garantit pas automatiquement qu’une modification a survécu à un redémarrage, atteint toutes les répliques, déclenché un équipement physique, réglé une transaction externe ou respecté une procédure d’approbation.

Ces affirmations appartiennent à des plans de contrôle différents. La durabilité demande une lecture après la frontière de persistance. L’action extérieure demande une observation du système qui l’exécute. Le mandat humain demande une trace de l’organisation responsable. La discipline n’est pas d’alourdir la capability jusqu’à en faire une bureaucratie complète, mais d’empêcher son résultat étroit de devenir une preuve universelle.

Sources