Решения ниже используют пространства имен через unshareкоманду. Процессы в других пространствах имен не увидят монтирование.
Мы не можем использовать, unshare -rпотому что он запускается с nogroupsправами группы, что не нравится encfs / fuse.
Решение 1 (будет запрашивать рут права при каждом запуске)
Мы используем sudo unshareдля создания привязки и пометить его как частное. После этого мы меняем пользователя на sudo caller ( sudo -u "#$SUDO_UID" -g "#$SUDO_GID") и заканчиваем явным образом удалять права root ( sudo -K). В этот момент мы можем позвонить encfsи начать делать вещи с your_program_here. После завершения монтирование частного связывания удаляется родительским корневым bash (поэтому без повторного запроса пароля пользователя root), поэтому он больше не виден через root mount -l.
enc_dir="/path/to/enc_dir" mount_point="/path/to/plain_dir" RUN_CMD="mount --bind \"$mount_point\" \"$mount_point\"; \ mount --make-private \"$mount_point\"; \ sudo -u \"#\$SUDO_UID\" -g \"#\$SUDO_GID\" \ bash -c \"sudo -K; \ encfs \\\"$enc_dir\\\" \\\"$mount_point\\\"; \ your_program_here \\\"\\\$@\\\"; \ fusermount -u -z \\\"$mount_point\\\" \ \" - \"\$@\"; \ umount \"$mount_point\"" sudo unshare -m bash -c "$RUN_CMD" - "optional" "arguments" your_program_hereможет быть любым, например, bashдля командной строки. Вы можете передать аргументы этой программе ($ 1 = "необязательный" $ 2 = "аргументы") правильно.
Источник: Запустить команду sudoed после завершения скрипта? ответ от Celada + см. источники решения 2.
Решение 2 (имеет критическую уязвимость при использовании unshare> = v2.27.1)
Чтобы избежать unshareзапуска с правами root, нам нужно использовать бит setuid.
sudo groupadd unshare sudo adduser $USER unshare sudo chmod u+s /usr/bin/unshare sudo chown root:unshare /usr/bin/unshare Предупреждение : это вызывает уязвимость в последних версиях unshare (начиная с v2.27.1 ) и не должно использоваться, так как unshare больше не теряет root-права при выполнении команды, так что любой может иметь root-доступ. Обходной путь существует и описан здесь .
Затем (возможно, потребуется новый терминал):
unshare -m Теперь у нас должна быть оболочка со $знаком пользователя, а не со знаком #root. Теперь нам нужно явно указать privateили rprivateв опциях монтирования (объяснение в источниках ниже), а затем запустить encfs.
enc_dir="/path/to/enc_dir" mount_point="/path/to/plain_dir" sudo mount --bind "$mount_point" "$mount_point" sudo mount --make-private "$mount_point" encfs "$enc_dir" "$mount_point" Процессы, запущенные из этой оболочки, смогут просматривать точку монтирования. Другие процессы не будут.
Источник: Скрытие зашифрованной папки в общей системе без корневого доступа (unshare -m), которую прокомментировал Филипп Вендлер и Кант (' Wendler & Cant'), получают пространства имен монтирования для каждого процесса, чтобы получить ответ ub1quit33
Решение 3? (Лучший Представитель Породы)
Возможности дальнейшего изучения: Вероятно, нужно что-то сделать, поместив сценарий решения 1 в .shфайл и установив setuidбит + chown для него, как в решении 2. #$SUDO_*IDВозможно, необходимо заменить переменные чем-то другим, а sudo -Kэффективность нужно проверить.
Кроме того, переменные enc_dir и mount_point не должны быть параметризуемыми, поскольку они не используются безопасно. В противном случае они должны быть экранированы, или, что лучше, они должны быть переданы как первые параметры, не являющиеся общими (следовательно, $ @ следует заменить диапазоном позиционных параметров $ {@: 2}).
Или заполните запрос функции для поддержки encfs / fuse, unshare -rчтобы отменить совместную работу разработчиков ...