Zusammenfassung

  • RFC 959 definierte SMNT als optionalen Befehl zum Einhängen einer anderen Dateisystemstruktur, wobei Anmeldung, Abrechnung und Übertragungsparameter erhalten blieben.
  • Ein identischer Pfad konnte nach dem Wechsel ein anderes Objekt bezeichnen; der Namensraum gehört deshalb zur Ressourcenevidenz.
  • Der spätere Befehl HOST musste vor der Authentifizierung stehen, weil der virtuelle Host die zulässigen Authentisierungsmethoden und Benutzer bestimmen konnte.

Ein Wechsel ohne sichtbaren Bruch

Der Benutzer ist angemeldet, eine Kontoinformation wurde gegebenenfalls akzeptiert, Typ und Modus der Übertragung sind gesetzt. Dann fordert der Client mit SMNT eine andere Dateisystemstruktur an. Die Kontrollverbindung bleibt offen und die vertrauten Sitzungswerte bleiben bestehen.

RFC 959 nennt diese Erhaltung ausdrücklich. Das Argument ist ein Pfad zu einem Verzeichnis oder einer systemabhängigen Dateigruppe. Geändert wird also nicht notwendig der handelnde Principal, sondern der Kontext, in dem Dateinamen aufgelöst werden.

Gerade das Fortbestehen der Anmeldung ist die historische Pointe. Ohne neuen Login entsteht ein neuer Ressourcenhorizont. Identität und Namensraum sind Zustandskomponenten, keine Synonyme.

Drei Befehle, drei Reichweiten

CWD wechselt Arbeitsverzeichnis oder Datensatz, ohne Benutzer- und Kontoinformationen anzutasten. Die Bewegung bleibt innerhalb der aktuellen Struktur. REIN löscht dagegen Benutzer, Konto und Übertragungsparameter und bringt die Verbindung in einen Zustand ähnlich einer neu geöffneten Sitzung.

SMNT liegt dazwischen. Es ändert mehr als den Standort, aber weniger als die gesamte Sitzung. Nach CWD muss die relative Basis neu betrachtet werden. Nach SMNT muss der auflösende Namensraum neu betrachtet werden. Nach REIN sind Identität und Einstellungen nicht mehr gültige Annahmen.

Wer alle drei Vorgänge als Navigation protokolliert, verliert die Sicherheitsgrenze. Entscheidend ist nicht, wie klein der Befehl aussieht, sondern welche früheren Tatsachen er ungültig machen kann.

Derselbe Pfad ist nicht zwingend dasselbe Objekt

RFC 959 schreibt keine universelle Pfadkonvention vor. Die Syntax folgt den beteiligten Dateisystemen. Auch RFC 3659 behandelt Pfade außerhalb von TVFS als serverabhängig und empfiehlt Clients, empfangene Namen exakt aufzubewahren und unverändert zurückzusenden.

Exakte Wiedergabe schützt die Zeichenfolge. Sie schützt nicht ihre Bedeutung über einen Strukturwechsel hinweg. /mandanten/heute kann vor und nach SMNT gleich geschrieben sein und dennoch unter einer anderen Wurzel, auf einem anderen Medium oder mit einer anderen Richtlinie aufgelöst werden.

Eine belastbare Ressourcenspur braucht daher Serverendpunkt, authentifizierten Principal, gegebenenfalls virtuellen Host, eingehängte Struktur, Arbeitsverzeichnis, originale Pfaddarstellung und Zeitpunkt. Benutzer plus Pfad ist eine gut lesbare, aber unvollständige Identität des Zugriffs.

Die Quellen belegen keine einheitliche historische Implementierung. Die Dateigruppe war ausdrücklich systemabhängig und SMNT optional. Belegt ist die standardisierte Möglichkeit, den Auflösungskontext zu wechseln und andere Sitzungswerte dabei zu bewahren.

Warum Einhängen Zugriffskontrolle war

RFC 5797 ordnet SMNT der Klasse Zugriffskontrolle zu, kennzeichnet es als optional und als Bestandteil des Basisbestands. Die heutige IANA-Tabelle bewahrt diese Einordnung.

Das ist mehr als Taxonomie. Eine andere Struktur kann andere Objekte erreichbar machen und die Berechtigung für denselben Namen verändern. Erfolgreiche Authentifizierung ist keine pauschale Erlaubnis, beliebige Strukturen auszuwählen. Der Server muss sowohl den Wechsel als auch spätere Zugriffe im neuen Kontext autorisieren.

RFC 1123 zieht die Interoperabilitätslinie: CWD ist verpflichtend, SMNT bleibt optional. Bewegung im angebotenen Raum gehörte zum gemeinsamen FTP-Kern; der Austausch dieses Raums nicht.

Das IANA-Register für FTP-Befehle belegt die koordinierte Bezeichnung und dokumentierte Semantik. Es belegt weder aktuelle Unterstützung noch Berechtigung oder Ausführung. Selbst eine positive Sitzungsantwort beweist nur den akzeptierten Übergang, nicht die Objektgleichheit identischer Pfade davor und danach.

Die umgekehrte Reihenfolge bei HOST

RFC 7151 führte HOST zur Auswahl eines virtuellen Hosts auf einem gemeinsam genutzten FTP-Server ein. Die Auswahl muss vor der Authentifizierung erfolgen; danach ist 503 vorgesehen.

Der Grund liegt in der Abhängigkeit der Identität. Ein virtueller Host kann die verfügbaren Authentisierungsmethoden und die Menge autorisierter Benutzer bestimmen. Ein bereits bestätigter Principal darf nicht still in eine andere Autoritätsdomäne getragen werden.

HOST ersetzte SMNT nicht, und beide adressieren unterschiedliche Funktionen. Der Vergleich liefert dennoch eine Regel: Ändert ein Kontext nur den Ressourcenraum unter einer unabhängigen Identität, kann die Sitzung eventuell erhalten bleiben und die Autorisierung neu erfolgen. Bestimmt der Kontext, welche Identitäten gültig sind, muss er vor der Authentifizierung gewählt werden.

Das heutige Echo eines seltenen Befehls

Interaktive SMNT-Nutzung ist heute selten. Ihr Zustandsproblem lebt in Mandantenwechseln, Cloud-Projekten, Regionen und Container-Mount-Namespaces weiter. Eine menschliche oder technische Identität bleibt, während sich die sichtbare Ressourcenwelt ändert.

Diese Systeme sind keine Neuauflagen von FTP. Gemeinsam ist ihnen die Beweispflicht: Sie müssen offenlegen, welcher Kontext aktiv ist, Berechtigungen daran binden und ihn in der Auditspur bewahren.

Ein Principal ist kein Namensraum. Ein Pfad ist ohne Auflösungskontext kein Objekt. Eine fortlaufende Sitzung beweist kein fortlaufendes Ressourcenmodell. Weil die Anmeldung den Wechsel überstand, musste der Wechsel selbst ein eigenständiges Ereignis sein.

Quellen