Montowania SSHFS należą do użytkownika, nie do haka VPN

Założenie łatwo przyswoić i trudno zauważyć: hak połączenia VPN działa jako root, więc montowanie, które uruchamia, też powinno być zorganizowane jako root. To rozumowanie daje katalog zespołu, którego użytkownik pulpitu nie może otworzyć, montowanie, które znika przy restarcie usługi wyzwalającej, oraz prośbę o uwierzytelnienie w kontekście, w którym nikt nie może na nią odpowiedzieć. Hak i montowanie to dwa różne zadania, a tylko jedno z nich potrzebuje uprawnień.

Mit: uprawnienia sieciowe oznaczają uprawnienia do montowania

Podniesienie interfejsu i uwierzytelnienie na serwerze plików to niepowiązane umiejętności i zwykle należą do różnych kont. Komponent VPN potrzebuje wystarczających uprawnień do zmiany tras i interfejsów. Konto serwera plików potrzebuje klucza lub hasła, decyzji o kluczu hosta i katalogu domowego, w którym ma zamontować. Przekazanie danych logowania drugiego zadania pierwszej tożsamości to sposób, w jaki usługa sieciowa zaczyna trzymać klucz użytkownika.

Na laptopie jednego użytkownika może to być to samo konto, a ten zbieg okoliczności nie jest projektem.

Gdy uprzywilejowany hak wykona montowanie, trzy rzeczy po cichu idą źle. Montowanie należy do roota, agenta użytkownika nie ma w tym środowisku, a błędy pojawiają się w logu usługi sieciowej, a nie w sesji, której to dotyczy. Żadnego z nich nie naprawia dodanie opcji do polecenia montowania. Naprawia je oddanie zadania sesji, która posiada tożsamość.

Dlaczego montowanie należy do zalogowanego użytkownika

Montowanie SSHFS to montowanie FUSE należące do procesu, który je utworzył, a dostęp idzie za tą własnością, nie za trybem katalogu nadrzędnego. Dokumentacja zaleca zwykłego użytkownika z punktem montowania, którego ten użytkownik jest właścicielem, i właśnie dlatego montowanie utworzone przez proces root jest niewygodne dla wszystkich innych. Zmiana uprawnień w punkcie montowania tego nie naprawia, bo przeszkodą jest właściciel samego montowania.

Zacznij od ręcznej linii bazowej w sesji użytkownika: istniejący pusty punkt montowania w katalogu domowym, autoryzowane konto na serwerze i klucz hosta już zweryfikowany przez zatwierdzony proces. Zamontuj go raz ręcznie i używaj, bo to dowodzi, że ścieżka tożsamości działa, zanim powstanie jakakolwiek automatyzacja. Zanotuj, czego potrzebowało polecenie: nazwę konta, ścieżkę eksportu i prywatną nazwę hosta. Zachowaj dokładnie ten kontekst dla wersji automatycznej, bo działające ręczne montowanie jest specyfikacją, którą wyzwalacz musi odtworzyć.

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

Traktuj każdą nazwę i każdą ścieżkę w tym wierszu jako symbol zastępczy, łącznie z kontem i eksportem. Hasło konta VPN nie jest automatycznie danymi logowania konta magazynu.

O co wyzwalacz powinien poprosić sesję

Wspierane rozwiązanie to żądanie ze zdarzenia sieciowego do sesji użytkownika, a nie pożyczone dane logowania. Ogranicz wyzwalacz do połączenia, o które chodzi, według nazwy lub UUID, a nie do dowolnego interfejsu, który przypadkiem nazywa się tun0. Ta jedna zmiana nie pozwala drugiemu profilowi, tunelowi testowemu ani sesji debugowania kolegi rozpocząć montowania.

Działanie po stronie sesji powinno znaleźć zamierzone istniejące montowanie, a potem wykonać jedną ograniczoną próbę.

Nie ponawiaj przy każdym odpytywaniu i nie proś w kółko o dane logowania, gdy serwer jest nieosiągalny, bo jedno i drugie zamienia chwilową awarię w zablokowanie konta. Usługa bez nadzoru to osobny projekt z własnymi zatwierdzonymi danymi logowania i własną weryfikacją hosta we własnym kontekście wykonania, i nie może liczyć na to, że ktoś odblokował agenta graficznego. Zdecyduj, który z dwóch budujesz, zanim wybierzesz, gdzie mieszka kod. Większość zamieszania tutaj bierze się z budowania jednego i oczekiwania drugiego.

Rozłączenie jest zdarzeniem systemu plików, nie zdarzeniem haka

Planowane rozłączenie powinno dokończyć operacje na plikach i odmontować z sesji montującego użytkownika wspieranym poleceniem dla tego typu systemu plików. Wymuszanie odłączenia, żeby hak szybko wrócił, to sposób, w jaki aplikacje tracą katalog roboczy, a użytkownicy zaufanie do automatyzacji. Zajęte montowanie potrzebuje decyzji na poziomie aplikacji, na przykład zamknięcia pliku lub zatrzymania zapisu, a nie silniejszego sygnału. Status wyjścia haka nie jest tym, co się optymalizuje.

fusermount3 -u "$HOME/mnt/team"

Nieoczekiwana utrata to inny przypadek, a SSHFS dokumentuje, że przerwana operacja może się zablokować, gdy transport łączy się ponownie.

Opcja ponownego połączenia przywraca transport, a pliki otwarte przed tym połączeniem nadal mogą zwracać błędy i wymagać ponownego otwarcia. Wracający VPN niczego nie dowodzi o wcześniejszych uchwytach ani niezapisananej pracy. Wybierz zachowanie, którego chcesz przy awarii — wstrzymanie, pokazanie błędu czy świadome ponowne montowanie — i przetestuj je na plikach jednorazowych, zanim cokolwiek od niego zależy.