Что делает параметр NO_ALL_SQUASH в экспорте NFS?

От экспорт (5) справочная страница, в разделе «Сопоставление идентификатора пользователя» говорится:

Сопоставление идентификатора пользователя

...

Очень часто нежелательно, чтобы пользователь root на клиентской машине также рассматривался как пользователь root при доступе к файлам на сервере NFS. С этой целью uid 0 обычно сопоставляется с другим id: так называемым анонимным или никто жидкость Этот режим работы (называемый «раздавливание корней») используется по умолчанию, и его можно отключить с помощью no_root_squash.

...

Вот полный список параметров сопоставления:

root_squash

Сопоставьте запросы от uid/gid 0 с анонимным uid/gid. Обратите внимание, что это не относится к каким-либо другим идентификаторам uid или gid, которые могут быть столь же чувствительными, как, например, пользовательский мусорное ведро или группа штат сотрудников.

no_root_squash

Отключите раздавливание корней. Эта опция в основном полезна для бездисковых клиентов.

all_squash

Сопоставьте все uid и gids с анонимным пользователем. Полезно для NFS-экспортированных общедоступных каталогов FTP, каталогов очереди новостей и т. д. Противоположным вариантом является no_all_squash, что является настройкой по умолчанию.

...

Я суммировал параметры сопоставления UID в следующей таблице (предполагается, что 1000 быть UID непривилегированного пользователя и 65534 быть анонимным UID):

После настройки пары NFS-сервера и клиента в виртуальной среде я обнаружил следующий результат:

Другими словами, no_all_squash вариант ведет себя так же, как root_squash вариант. Это отвечает на вопрос 1 и одновременно объясняет вопрос 2.

Корневой сквош / отсутствие корневого сквош не имеет отношения к идентификатору клиента, который вы увидите при чтении / записи, только к тому, разрешено ли root вмешиваться и вносить изменения независимо от того, включено ли оно в разрешение или нет установлен. Root squash не позволит локальному root изменить владельца файлов.

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

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

Сквоширование используется в некоторых редких случаях, когда, с одной стороны, вы хотите разрешить доступ по NFS к некоторым клиентам, которые не твой, а с другой стороны, вы не хотите, чтобы они имели полный доступ, если они используют идентификатор 0. Обычно NFS настраивается в сети одной организации, где все машины управляются одной командой инженеров.

Что касается всех/никаких сжатий/не сжатий - конец был прост: если вы хотите применить какие-то сложные ACL для вашего дерева файловой системы, вы должны использовать NFSv4, который правильно обрабатывает ACL, потому что NFSv<=3 просто не делает этого, со сжатием или без него (последнее только делает модель доступа NFSv<=3 громоздкой, но не полной). Последняя часть была главной причиной появления NFSv4.