Résumé

  • Une ACL de boîte IMAP réunit des couples identifiant-droits. Un utilisateur peut correspondre à son nom, à plusieurs groupes et à anyone : une entrée n’est qu’un élément du calcul.
  • GETACL expose les règles, LISTRIGHTS ce que le serveur sait accorder à un identifiant, MYRIGHTS le résultat effectif pour la session courante.
  • DELETEACL efface un couple ; un identifiant négatif retire un droit lors du calcul. RFC 4314 précisa cette différence sans imposer à tous les serveurs le même modèle d’identité.

Le geste net de l’interface

Un écran de permissions raconte une histoire rassurante. On choisit une personne, on efface sa ligne, on enregistre : l’accès serait terminé. Ce récit suppose pourtant que cette ligne était l’unique chemin vers le droit, que le serveur d’exécution a recalculé la décision et qu’aucune session ne conserve l’ancien résultat.

Les boîtes collectives révélaient tôt cette faiblesse. Un dossier d’assistance appartenait à une équipe ; un agent pouvait disposer d’une autorisation directe, hériter d’un groupe et recevoir un droit plus large. La liste énumérait des motifs. Elle n’était pas la décision finale.

RFC 1730 avait défini la boîte distante comme un objet manipulable : un client sélectionnait des dossiers, lisait des messages, modifiait des indicateurs et agissait sur l’état conservé par le serveur. Dès que plusieurs personnes partageaient cet objet, une permission enfermée dans le système de fichiers local ne suffisait plus. Le client distant devait interroger l’autorité qui exécuterait sa prochaine commande.

Publié sur le Standards Track en janvier 1997, RFC 2086 ajouta cette surface. Un serveur annonçait la capacité ACL. Pour chaque boîte, l’ACL formait un ensemble de couples associant un identifiant à une chaîne de droits. Le protocole rendait ces couples consultables et modifiables sans exporter tout l’annuaire local.

Plusieurs identités pour une même session

Le modèle devenait intéressant dès qu’on demandait ce qu’était un identifiant. anyone désignait l’identité universelle, y compris l’accès anonyme. Les noms acceptés par LOGIN ou AUTHENTICATE correspondaient aux utilisateurs. Les autres chaînes pouvaient représenter des groupes ou des catégories propres à l’implémentation.

Un même utilisateur pouvait donc correspondre à fred, equipe-support et anyone. RFC 2086 ne décréta pas une algèbre unique. Un serveur pouvait réunir les droits de tous les identifiants applicables ; un autre pouvait retenir seulement le plus spécifique. La règle de combinaison demeurait locale.

Cette marge n’autorisait pas le client à inventer sa réponse. Une interface voyait les lignes, pas forcément les groupes réels, les droits imposés au propriétaire ni la priorité des entrées. Deux serveurs conformes pouvaient calculer des résultats différents à partir de listes semblables.

La solution ne fut pas un registre mondial des identités. MYRIGHTS demandait au serveur les droits effectifs de l’utilisateur connecté sur une boîte. Le composant chargé d’accepter ou de refuser l’opération suivante exposait ainsi son propre verdict.

Une liste, une possibilité, un résultat

Trois commandes dessinaient trois plans qu’il ne fallait pas superposer.

GETACL renvoyait les couples enregistrés. Il répondait à la question : quelles règles sont déclarées sur cette boîte ? Il ne disait ni lesquelles concernaient la session, ni comment elles seraient combinées.

LISTRIGHTS indiquait, pour une boîte et un identifiant, les droits que le serveur pouvait accorder. Certaines lettres pouvaient être obligatoires, d’autres liées parce que le modèle sous-jacent ne savait pas les séparer. La commande décrivait le vocabulaire réellement exprimable par cette implémentation.

MYRIGHTS donnait l’ensemble final pour l’utilisateur courant. Il répondait à la seule question opérationnelle : après résolution des identités et application des règles locales, que le serveur permettra-t-il à cette session ?

Une relecture réussie de l’ACL prouve une écriture déclarative. MYRIGHTS prouve un calcul courant pour une session. L’acceptation de l’action protégée prouve encore autre chose. Aucun de ces éléments ne révèle à lui seul l’être humain qui contrôle les justificatifs d’authentification.

Effacer une entrée n’effaçait pas ses autres chemins

DELETEACL boite fred retirait le couple nommé fred. Si Fred recevait encore w par un groupe ou par anyone, la commande pouvait réussir parfaitement et laisser son écriture effective intacte.

RFC 2086 réservait aussi les identifiants commençant par un tiret aux droits négatifs. RFC 4314 explicita leur rôle. Une entrée -fred munie de w soustrayait le droit d’écrire associé à Fred, même si un autre identifiant applicable le lui accordait. L’entrée négative participait au calcul ; DELETEACL ne faisait que retirer un couple.

Le serveur n’était toutefois pas obligé de prendre en charge ces identifiants négatifs. Un client ne pouvait pas promettre partout un bouton « refus prioritaire ». Il devait découvrir la capacité réelle puis vérifier le résultat.

Le même tiret apparaissait à deux endroits sans avoir le même pouvoir. Dans l’argument de droits de SETACL, -w retirait la lettre w d’une entrée déterminée. Dans la place de l’identifiant, -fred créait un terme négatif du calcul. Le premier modifiait une ligne ; le second pouvait neutraliser une voie d’héritage.

Affiner sans rompre

La première extension codait par lettres la visibilité, la lecture, l’état lu/non lu, les autres drapeaux, l’insertion, la publication, la création, la suppression et l’administration. Des ambiguïtés apparurent autour de c et d : supprimer un message, l’expurger et supprimer la boîte entière n’étaient pas le même pouvoir.

RFC 4314 remplaça RFC 2086 en décembre 2005. Il attribua k à la création de sous-boîtes, x à la suppression ou au déplacement d’une boîte, t au marquage d’un message comme supprimé et e à l’expurgation. Les anciens c et d restèrent des droits virtuels de compatibilité. Un vieux client recevait une projection définie ; un nouveau serveur pouvait exercer un contrôle plus fin.

Cette transition refusa l’illusion d’un grand remplacement instantané. La capacité RIGHTS= annonçait les droits supplémentaires. Les implémentations pouvaient conserver des droits liés lorsque leur stockage ne savait pas les dissocier, à condition de le rendre observable par LISTRIGHTS.

Le nouveau texte imposa aussi une discipline aux éditeurs partiels. Un client capable de lire et de réécrire une ACL devait préserver les droits inconnus qu’il ne permettait pas de modifier. Sinon, un logiciel ancien aurait détruit, à la sauvegarde, une permission apparue après lui. Ne pas comprendre devenait une raison de conserver, non une licence d’effacer.

La révocation n’avait pas un instant universel

RFC 4314 autorisait le serveur à mémoriser les droits lors de la sélection d’une boîte. Après SETACL ou DELETEACL, une session déjà ouverte pouvait donc continuer à exécuter certaines commandes jusqu’à une nouvelle sélection. Un serveur recalculant à chaque commande pouvait actualiser les indicateurs, refuser l’action ou fermer la connexion si le droit de lecture disparaissait.

Le standard ne promit pas un point de révocation simultané pour toutes les sessions. Il indiqua la frontière à éprouver. En revanche, dans une même connexion, une séquence envoyant SETACL puis MYRIGHTS devait être ordonnée : le changement devait finir avant le calcul du second résultat.

Ainsi, un journal « modification réussie » ne suffisait pas. Il fallait savoir quelle session, quel état sélectionné et quel acte avaient réellement subi la nouvelle décision.

Voir la règle pouvait déjà révéler le secret

Une ACL ne contient pas le courrier, mais dévoile l’existence de la boîte, des noms d’utilisateurs, des groupes et des administrateurs. RFC 2086 exigeait déjà qu’un GETACL non autorisé ne révèle pas une boîte protégée. RFC 4314 renforça le principe : sans droit de visibilité, la réponse devait ressembler à celle d’une boîte inexistante.

Le droit de lire les messages ne donnait plus automatiquement le droit d’examiner la liste, car celle-ci révélait l’architecture des identités. Et le protocole ACL ne chiffrait pas ce renseignement. Sans STARTTLS, protection négociée dans l’authentification ou autre mécanisme de confidentialité, les entrées circulaient en clair.

Une décision d’autorisation correcte n’était donc pas une protection du canal qui la transportait.

Le reste local était déclaré, non caché

RFC 4314 énuméra ses propres insuffisances. La combinaison des identités restait propre à l’implémentation. Utilisateurs, groupes et identifiants spéciaux partageaient le même espace. Une interface générique peinait à expliquer ces différences. Les opérations ne reproduisaient pas toute la richesse d’un système de fichiers.

La révision fut néanmoins jugée utile parce que RFC 2086 était déjà déployé dans plusieurs implémentations. RFC 9051 définit plus tard IMAP4rev2 et conserva en général la validité des extensions enregistrées d’IMAP4rev1. Cette continuité ne prouve ni une adoption universelle ni la présence des droits négatifs chez un fournisseur donné.

L’héritage est plus précis : le protocole commun ne s’est pas proclamé maître des identités locales. Il a standardisé les questions minimales permettant à un client de ne pas confondre la règle enregistrée, la modification représentable et le droit effectivement exécuté.

Sources