Zusammenfassung

  • Eine IMAP-ACL besteht aus Paaren von Kennung und Rechten. Ein Nutzer kann zugleich auf seinen Namen, mehrere Gruppen und anyone passen; eine Zeile ist deshalb nur ein Eingangswert der Entscheidung.
  • GETACL zeigt gespeicherte Regeln, LISTRIGHTS die für eine Kennung vergebbaren Rechte und MYRIGHTS das wirksame Ergebnis für die angemeldete Sitzung.
  • DELETEACL entfernt ein Paar. Eine negative Kennung zieht Rechte während der Berechnung ab. RFC 4314 klärte den Unterschied, ohne jedes lokale Identitätsmodell zu vereinheitlichen.

Der saubere Verwaltungsakt mit offenem Ausgang

Eine Rechteverwaltung erzählt eine einfache Geschichte: Name markieren, Zeile löschen, speichern. Zur echten Sperre wird dieser Akt nur, wenn die Zeile der einzige Berechtigungspfad war, der ausführende Server neu gerechnet hat und keine bestehende Sitzung den alten Zustand weiterführt.

Gemeinsam genutzte Postfächer machten das Problem früh sichtbar. Eine Support-Ablage gehörte einem Team. Ein Mitarbeiter konnte ein persönliches Recht besitzen, ein zweites über die Gruppe und ein drittes über eine breite Regel. Die Liste enthielt Gründe für Zugriff, nicht zwingend das Endergebnis.

RFC 1730 hatte das entfernte Postfach als über das Netz bearbeitbares Objekt beschrieben. Clients wählten Ordner, lasen Nachrichten, setzten Markierungen und veränderten den Zustand auf dem Server. Sobald mehrere Menschen dasselbe Objekt nutzten, reichten nur lokal sichtbare Dateirechte nicht mehr. Der entfernte Client musste die Instanz befragen können, die seinen nächsten Befehl ausführen würde.

Im Januar 1997 ergänzte RFC 2086 auf dem Standards Track die Fähigkeit ACL. Eine Postfach-ACL war eine Menge aus Kennung-Rechte-Paaren. Der Client konnte sie lesen und ändern, ohne das gesamte lokale Konto- und Gruppensystem zu erhalten.

Eine Sitzung traf unter mehreren Kennungen ein

anyone bezeichnete die universelle Identität einschließlich anonymer Zugriffe. Von LOGIN oder AUTHENTICATE akzeptierte Namen standen für die jeweiligen Nutzer. Andere Zeichenfolgen konnten Gruppen oder andere implementierungsspezifische Kategorien sein.

Fred konnte daher gleichzeitig fred, support-team und anyone entsprechen. Die RFC schrieb keine einzige Verknüpfungsregel vor. Ein Server durfte alle zutreffenden Rechte vereinigen; ein anderer durfte nur die spezifischste Kennung heranziehen.

Diese Freiheit lag beim ausführenden System, nicht bei der grafischen Oberfläche. Sie sah Zeilen, aber nicht unbedingt reale Gruppenmitgliedschaften, erzwungene Eigentümerrechte oder Prioritäten. Zwei konforme Server konnten aus ähnlich aussehenden Listen verschiedene Befugnisse bilden.

Die Lösung war kein zentrales Identitätsregister. MYRIGHTS fragte den Server nach den wirksamen Rechten des angemeldeten Nutzers auf dem Postfach. Der spätere Entscheider legte damit seinen gegenwärtigen Rechenstand offen.

Drei Antworten statt einer grünen Anzeige

GETACL lieferte die gespeicherten Paare. Es beantwortete, welche Regeln erklärt waren, nicht welche davon auf die Sitzung passten oder wie sie zusammenwirkten.

LISTRIGHTS zeigte, was einer bestimmten Kennung überhaupt erteilt werden konnte. Manche Rechte waren zwingend, andere nur als verbundenes Bündel möglich, wenn das lokale Modell sie nicht trennen konnte. Die Antwort beschrieb die Ausdrucksfähigkeit des Servers, nicht die aktuelle Erlaubnis.

MYRIGHTS lieferte das Ergebnis nach Kennungsauflösung und lokaler Kombination. Es war der wirksame Blick für diese Sitzung, ohne automatisch alle Quellen oder die Person hinter den Anmeldedaten zu beweisen.

Ein erfolgreiches Zurücklesen der ACL, ein MYRIGHTS-Ergebnis und die Annahme eines geschützten Befehls sind drei verschiedene Belege. Gute Verwaltung bewahrt diese Stufen, statt eine davon zum Ersatz für alle anderen zu erklären.

Einen Grund entfernen oder ein Recht abziehen

DELETEACL mailbox fred entfernte Freds Paar. Kam w weiterhin über eine Gruppe oder anyone, erfüllte der Befehl seinen Vertrag und ließ die Schreibberechtigung bestehen.

RFC 2086 reservierte Kennungen mit führendem Bindestrich für negative Rechte. RFC 4314 erklärte den Unterschied ausdrücklich. Ein Eintrag -fred mit w zog Fred das Schreibrecht ab, selbst wenn eine andere passende Kennung es verlieh. Der negative Eintrag nahm an der Berechnung teil; DELETEACL entfernte nur einen Baustein.

Server mussten negative Kennungen nicht unterstützen. Ein Client durfte aus der Existenz der Schreibweise keinen universellen „Verbot schlägt Erlaubnis“-Schalter ableiten. Er musste die Fähigkeit feststellen und das wirksame Ergebnis prüfen.

Auch der Bindestrich hatte zwei Ebenen. Im Rechteargument von SETACL nahm -w das Recht aus dem ausgewählten Paar. An der Kennungsstelle bezeichnete -fred einen negativen Berechnungseintrag. Das erste war Zeilenbearbeitung, das zweite konnte geerbte Autorität neutralisieren.

Feinere Rechte mit Rückweg für alte Clients

Die Fassung von 1997 kodierte Sichtbarkeit, Lesen, Gesehen-Status, andere Markierungen, Einfügen, Posten, Erstellen, Löschen und Verwalten in Buchstaben. Vor allem c und d waren zu grob: Eine Nachricht zum Löschen zu markieren, sie endgültig zu entfernen und das ganze Postfach zu löschen sind verschiedene Eingriffe.

RFC 4314 ersetzte RFC 2086 im Dezember 2005. k regelte das Anlegen untergeordneter Postfächer, x das Löschen oder Verschieben eines Postfachs, t die Gelöscht-Markierung und e das endgültige Entfernen von Nachrichten. Die alten c und d blieben virtuelle Kompatibilitätsrechte. Neue Server konnten fein entscheiden und alten Clients eine definierte gröbere Projektion geben.

RIGHTS= kündigte zusätzliche Rechte an. Musste eine Implementierung mehrere Rechte gemeinsam vergeben, machte LISTRIGHTS die Bindung sichtbar. Der gemeinsame Standard behauptete nicht, alle lokalen Systeme besäßen dieselbe Granularität.

Ein schreibender Client musste zudem unbekannte Rechte bewahren, die er nicht bearbeiten konnte. Sonst hätte eine alte Oberfläche einen modernen Eintrag gelesen und beim Speichern jede neue, unverstandene Berechtigung gelöscht. Erweiterbarkeit verlangte konservativen Umgang mit Unwissen.

Widerruf hatte eine Sitzungszeit

RFC 4314 erlaubte dem Server, Rechte beim Auswählen eines Postfachs zwischenzuspeichern. Nach SETACL oder DELETEACL konnten STORE oder EXPUNGE in einer bereits ausgewählten Sitzung bis zur erneuten Auswahl noch nach der alten Entscheidung laufen.

Ein Server mit Prüfung bei jedem Befehl konnte Markierungen aktualisieren, Vorgänge verweigern oder die Verbindung schließen, wenn das Leserecht verschwand. Einen globalen, gleichzeitigen Widerrufszeitpunkt für alle Sitzungen versprach die Spezifikation nicht. Sie benannte die Grenze, die Betreiber testen mussten.

Innerhalb einer Verbindung ließ sich Ordnung herstellen. Bei einer Pipeline aus SETACL und MYRIGHTS musste die Änderung abgeschlossen sein, bevor die zweite Antwort berechnet wurde. Über den Cache einer anderen Verbindung sagte diese Ordnung nichts.

Schon die Liste war schützenswert

Eine ACL konnte die Existenz eines Postfachs, Konten, Gruppen und Administratoren verraten. RFC 2086 warnte vor dieser Offenlegung; RFC 4314 verlangte ohne ausreichendes Sichtrecht dieselbe Antwort wie für ein nicht vorhandenes Postfach.

Das Recht, Nachrichten zu lesen, genügte nicht automatisch zum Abruf der ACL. Die Identitätsstruktur war eigene Sicherheitsinformation. Und die ACL-Erweiterung verschlüsselte sie nicht: Ohne STARTTLS, ausgehandelten Schutz bei der Authentifizierung oder eine andere Vertraulichkeitsschicht liefen die Daten im Klartext.

Korrekte Autorisierung und geschützter Transport blieben getrennte Pflichten.

Der lokale Rest wurde eingestanden

RFC 4314 nannte bekannte Schwächen: Die Kombination blieb implementierungsspezifisch, Nutzer, Gruppen und Sonderkennungen teilten einen Namensraum, eine allgemein verständliche Oberfläche war begrenzt, und vollständige Eigentümeroperationen eines Dateisystems fehlten.

Die rückwärtskompatible Verbesserung galt dennoch als sinnvoll, weil RFC 2086 in mehreren Implementierungen eingesetzt war. RFC 9051 definierte später IMAP4rev2 und ließ registrierte IMAP4rev1-Erweiterungen grundsätzlich weiter gelten. Das belegt Protokollkontinuität, nicht universelle heutige Nutzung von ACL oder negativen Rechten.

Die bleibende Leistung war kleiner: Der Standard machte nicht die sichtbare Liste zum Souverän. Er gab dem Client gemeinsame Fragen, mit denen gespeicherte Regeln, mögliche Änderungen und die wirksame Entscheidung des laufenden Servers auseinanderzuhalten waren.

Quellen