SSHFS-Mounts gehören dem Benutzer, nicht dem VPN-Hook

Die Annahme ist leicht zu übernehmen und schwer zu bemerken: Ein VPN-Verbindungs-Hook läuft als root, also sollte auch der Mount, den er startet, als root eingerichtet werden. Diese Argumentation erzeugt ein Teamverzeichnis, das der Desktop-Benutzer nicht öffnen kann, einen Mount, der verschwindet, wenn der auslösende Dienst neu startet, und eine Authentifizierungsaufforderung in einem Kontext, in dem niemand sie beantworten kann. Der Hook und der Mount sind zwei verschiedene Aufgaben, und nur eine davon braucht Rechte.

Der Mythos: Netzwerkrechte bedeuten Mount-Rechte

Eine Schnittstelle hochzufahren und sich an einem Dateiserver zu authentifizieren sind unverbundene Fähigkeiten und gehören normalerweise zu verschiedenen Konten. Die VPN-Komponente braucht genug Rechte, um Routen und Schnittstellen zu ändern. Das Dateiserver-Konto braucht einen Schlüssel oder ein Passwort, eine Entscheidung zum Hostschlüssel und ein Heimatverzeichnis zum Einbinden. Die Anmeldedaten der zweiten Aufgabe an die erste Identität zu geben, ist der Weg, auf dem ein Netzwerkdienst den Schlüssel eines Benutzers hält.

Auf einem Laptop mit einem einzigen Benutzer kann das dasselbe Konto sein, und dieser Zufall ist kein Entwurf.

Sobald ein privilegierter Hook das Einbinden übernimmt, gehen drei Dinge still schief. Der Mount gehört root, der Agent des Benutzers fehlt in dieser Umgebung, und Fehler erscheinen im Protokoll des Netzwerkdienstes statt in der Sitzung, der es wichtig ist. Nichts davon wird repariert, indem man der Mount-Kommandozeile Optionen hinzufügt. Es wird repariert, indem man die Aufgabe der Sitzung gibt, die die Identität besitzt.

Warum der Mount dem angemeldeten Benutzer gehört

Ein SSHFS-Mount ist ein FUSE-Mount, der dem Prozess gehört, der ihn erzeugt hat, und der Zugriff folgt diesem Eigentum statt dem Modus des übergeordneten Verzeichnisses. Die Referenz empfiehlt einen normalen Benutzer mit einem Einhängepunkt, der diesem Benutzer gehört, und genau deshalb ist ein von einem root-Prozess erzeugter Mount für alle anderen unhandlich. Eine Berechtigungsänderung am Einhängepunkt repariert das nicht, denn das Hindernis ist der Eigentümer des Mounts selbst.

Beginnen Sie mit einer manuellen Grundlinie innerhalb der Benutzersitzung: ein vorhandener leerer Einhängepunkt unter dem Heimatverzeichnis, ein autorisiertes Konto auf dem Server und ein Hostschlüssel, der bereits durch Ihr genehmigtes Verfahren verifiziert wurde. Binden Sie ihn einmal von Hand ein und benutzen Sie ihn, denn das beweist, dass der Identitätsweg funktioniert, bevor es irgendeine Automatisierung gibt. Notieren Sie, was das Kommando brauchte: den Kontonamen, den Exportpfad und den privaten Hostnamen. Behalten Sie genau diesen Kontext für die automatisierte Version, denn ein funktionierender manueller Mount ist die Spezifikation, die der Auslöser reproduzieren muss.

sshfs [email protected]:/exports/team "$HOME/mnt/team"

Behandeln Sie jeden Namen und jeden Pfad in dieser Zeile als Platzhalter, einschließlich Konto und Export. Ein VPN-Kontopasswort ist nicht automatisch die Anmeldeinformation des Speicherkontos.

Was der Auslöser die Sitzung bitten sollte zu tun

Die unterstützte Anordnung ist eine Anfrage vom Netzwerkereignis an die Benutzersitzung, keine geliehene Anmeldeinformation. Beschränken Sie den Auslöser auf die Verbindung, die Sie meinen, per Name oder UUID, statt auf jede Schnittstelle, die zufällig tun0 heißt. Diese eine Änderung hindert ein zweites Profil, einen Testtunnel oder die Debugging-Sitzung eines Kollegen daran, einen Mount zu starten.

Die sitzungsseitige Aktion sollte den beabsichtigten vorhandenen Mount suchen und dann einen begrenzten Versuch machen.

Versuchen Sie nicht bei jeder Abfrage erneut und fordern Sie keine Anmeldedaten an, solange der Server nicht erreichbar ist, denn beides verwandelt eine vorübergehende Störung in eine Kontosperre. Ein unbeaufsichtigter Dienst ist ein getrenntes Design mit eigenen genehmigten Anmeldedaten und eigener Hostverifikation in seinem eigenen Ausführungskontext und kann nicht darauf bauen, dass jemand einen grafischen Agenten entsperrt hat. Entscheiden Sie, welches der beiden Sie bauen, bevor Sie wählen, wo der Code lebt. Der meiste Wirrwarr hier entsteht daraus, das eine zu bauen und das andere zu erwarten.

Trennen ist ein Dateisystemereignis, kein Hook-Ereignis

Ein geplantes Trennen sollte Dateioperationen abschließen und aus der Sitzung des einbindenden Benutzers mit dem unterstützten Kommando für diesen Dateisystemtyp aushängen. Ein Trennen zu erzwingen, damit ein Hook schnell zurückkehrt, ist der Weg, auf dem Anwendungen ihr Arbeitsverzeichnis und Benutzer das Vertrauen in die Automatisierung verlieren. Ein beschäftigter Mount braucht eine Entscheidung auf Anwendungsebene, etwa die Datei zu schließen oder das Schreiben zu stoppen, kein stärkeres Signal. Der Exit-Status des Hooks ist nicht das, was optimiert wird.

fusermount3 -u "$HOME/mnt/team"

Unerwarteter Verlust ist ein anderer Fall, und SSHFS dokumentiert, dass eine unterbrochene Operation blockieren kann, während der Transport sich wieder verbindet.

Die Wiederverbindungsoption stellt den Transport wieder her, und Dateien, die vor dieser Wiederverbindung geöffnet wurden, können weiterhin Fehler zurückgeben und müssen erneut geöffnet werden. Ein zurückkehrendes VPN beweist nichts über frühere Handles oder ungespeicherte Arbeit. Wählen Sie das Verhalten, das Sie bei einer Störung wollen — pausieren, einen Fehler anzeigen oder bewusst neu einbinden — und testen Sie es mit Wegwerfdateien, bevor irgendetwas davon abhängt.