Монтирования SSHFS принадлежат пользователю, а не VPN-хуку

Допущение легко усвоить и трудно заметить: хук подключения VPN работает как root, поэтому и монтирование, которое он запускает, должно быть организовано как root. Такое рассуждение порождает командный каталог, который пользователь рабочего стола не может открыть, монтирование, исчезающее при перезапуске службы-триггера, и запрос аутентификации в контексте, где никто не может на него ответить. Хук и монтирование — две разные задачи, и только одной из них нужны привилегии.

Миф: сетевые привилегии означают привилегии монтирования

Поднятие интерфейса и аутентификация на файловом сервере — несвязанные возможности, и обычно они принадлежат разным учётным записям. Компоненту VPN нужны достаточные привилегии для изменения маршрутов и интерфейсов. Учётной записи файлового сервера нужен ключ или пароль, решение насчёт ключа хоста и домашний каталог для монтирования. Передача учётных данных второй задачи первой личности — это путь, которым сетевой сервис начинает хранить ключ пользователя.

На ноутбуке с одним пользователем это может быть одна и та же учётная запись, и такое совпадение не является проектом.

Как только привилегированный хук выполняет монтирование, три вещи тихо ломаются. Монтирование принадлежит root, агент пользователя отсутствует в этой среде, а ошибки появляются в журнале сетевого сервиса, а не в сессии, которой это важно. Ничего из этого не исправляется добавлением опций в команду монтирования. Это исправляется передачей задачи сессии, владеющей личностью.

Почему монтирование принадлежит вошедшему пользователю

Монтирование SSHFS — это монтирование FUSE, принадлежащее процессу, который его создал, и доступ следует за этим владением, а не за режимом родительского каталога. Справочное руководство рекомендует обычного пользователя с точкой монтирования, принадлежащей этому пользователю, и именно поэтому монтирование, созданное процессом root, неудобно для всех остальных. Смена прав на точке монтирования это не исправляет, потому что препятствие — сам владелец монтирования.

Начните с ручной базовой линии внутри сессии пользователя: существующая пустая точка монтирования под домашним каталогом, авторизованная учётная запись на сервере и ключ хоста, уже проверенный вашим утверждённым процессом. Смонтируйте вручную один раз и используйте, потому что это доказывает, что путь личности работает до появления любой автоматизации. Запишите, что потребовалось команде: имя учётной записи, путь экспорта и частное имя хоста. Сохраните именно этот контекст для автоматизированной версии, ведь работающее ручное монтирование — это спецификация, которую триггер должен воспроизвести.

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

Считайте каждое имя и путь в этой строке заполнителем, включая учётную запись и экспорт. Пароль учётной записи VPN не становится автоматически учётными данными учётной записи хранилища.

Что триггер должен попросить у сессии

Поддерживаемая схема — запрос от сетевого события к сессии пользователя, а не заимствованные учётные данные. Ограничьте триггер тем соединением, которое имеете в виду, по имени или UUID, а не любым интерфейсом, который случайно называется tun0. Это единственное изменение не даёт второму профилю, тестовому туннелю или отладочной сессии коллеги начать монтирование.

Действие на стороне сессии должно найти предполагаемое существующее монтирование и затем сделать одну ограниченную попытку.

Не повторяйте попытку при каждом опросе и не запрашивайте учётные данные, пока сервер недоступен, потому что и то и другое превращает кратковременный сбой в блокировку учётной записи. Служба без надзора — это отдельный проект с собственными утверждёнными учётными данными и собственной проверкой хоста в собственном контексте выполнения, и она не может рассчитывать на то, что кто-то разблокировал графический агент. Решите, что именно из двух вы строите, прежде чем выбирать, где живёт код. Большая часть путаницы здесь возникает из-за того, что строят одно, а ожидают другое.

Отключение — это событие файловой системы, а не событие хука

Плановое отключение должно завершить файловые операции и размонтировать из сессии монтирующего пользователя поддерживаемой командой для этого типа файловой системы. Принудительное отсоединение, чтобы хук быстро вернулся, — это путь, которым приложения теряют рабочий каталог, а пользователи — доверие к автоматизации. Занятому монтированию нужно решение на уровне приложения, например закрыть файл или остановить запись, а не более сильный сигнал. Код выхода хука — не то, что оптимизируется.

fusermount3 -u "$HOME/mnt/team"

Неожиданная потеря — другой случай, и SSHFS документирует, что прерванная операция может блокироваться, пока транспорт переподключается.

Параметр переподключения восстанавливает транспорт, а файлы, открытые до этого переподключения, всё ещё могут возвращать ошибки и нуждаться в повторном открытии. Вернувшийся VPN ничего не доказывает о прежних дескрипторах или несохранённой работе. Выберите желаемое поведение при сбое — пауза, показ ошибки или намеренное повторное монтирование — и проверьте его на одноразовых файлах, прежде чем что-либо от него зависит.