Решения ниже используют пространства имен через unshare команда. Процессы в других пространствах имен не увидят монтирование.

Мы не можем использовать unshare -r потому что он работает с nogroups групповые права, которые не нравятся encfs/fuse.

Решение 1 (будет запрашивать рут права при каждом запуске)

Мы используем sudo unshare создать привязку и пометить ее как частную. После этого мы меняем пользователя на sudo caller (sudo -u "#$SUDO_UID" -g "#$SUDO_GID") конец явно удалить рут права (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

Теперь мы должны иметь оболочку с $ знак пользователя, а не # корневой знак Теперь нам нужно явно указать 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 бит + чоун на нем, как в решении 2. #$SUDO_*ID переменные, возможно, должны быть заменены чем-то еще и sudo -K эффективность должна быть проверена.

Кроме того, переменные enc_dir и mount_point не должны быть параметризуемыми, так как они не используются безопасно. В противном случае они должны быть экранированы, или, что лучше, они должны быть переданы как первые параметры, не являющиеся общими (следовательно, $@ следует заменить диапазоном позиционных параметров ${@:2}).

Или заполните запрос функции для поддержки encfs/fuse в unshare -r отменить обмен разработчиками...