☰

Параметр fsid NFSv4 и цель экспорта корней

tag-icon • tag-icon nfs4
Параметр fsid NFSv4 и цель экспорта корней

Мой файловый сервер просто имеет один большой раздел, разделяющий вещи в /exports. Поэтому, используя старый стиль экспорта NFSv3, у меня было:

/exports/home     192.168.1.0/24(rw,sync,no_subtree_check)
/exports/root     192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)

Поэтому я решил перейти на стиль NFSv4 и изменил его на:

/exports          192.168.1.0/24(ro,fsid=0,no_subtree_check)
/exports/home     192.168.1.0/24(rw,sync,no_subtree_check)
/exports/root     192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)
#/etc              192.168.1.0/24(ro,no_subtree_check) # Test entry to check export root is working.

Затем я изменил команды монтирования, чтобы исключить /exports. Конечно, монтирование /etcбыло невозможным (хотя это не было ошибкой, оно просто блокировалось до прерывания). Однако, как я и ожидал, /exportsACL 'а все еще наследовались сверху вниз, все общие ресурсы были только для чтения, а root был везде подавлен.

Я также пробовал изменить ACL для /exports/rootодной машины, но это не помогло.

Таким образом, помимо возможности предоставления уникального идентификатора для тех файловых систем, где такой идентификатор не может быть определен, какой смысл определять корень экспорта с помощью fsid=0:

  • Это снижает гибкость с точки зрения настройки общих ресурсов (т. е. проблемы наследования, если только вы не используете разные файловые системы nocrossmount?).
  • Если предположить, что используется старая версия NFSv3, вы все равно не сможете монтировать, /etcтак какую дополнительную безопасность она обеспечивает?

Имеет ли это fsid=0смысл только тогда, когда /exportsэто просто область монтирования для отдельных файловых систем, которые монтируются туда и экспортируются с разными списками контроля доступа?

Мне кажется, что настройка серверов NFS перевернута. Раньше на Solaris все общие файлы напрямую монтировались под /exportи выкладывались наружу. Сервер был бы /home/userсмонтирован с привязкой к /export/home/user. Но теперь /homeэто реальное место монтирования файловой системы, и оно смонтировано с привязкой к /exports.

Это верно?

Пожалуйста, обрати внимание: Приведенные выше примеры приведены только для иллюстрации, поэтому, пожалуйста, не комментируйте целесообразность не использования no_squash_root, я знаю.

Большое спасибо.

решение1

Это архитектурное изменение в работе протокола «монтирования» NFS.

В NFSv2/v3 был совершенно отдельный протокол RPC 'MOUNT', который позволял клиенту получать дескриптор файла любой экспортированной файловой системы по ее пути. Но в последующем WebNFS – и позже в NFSv4 – монтирование было изменено на внутриполосную операцию NFS, и в то же время операция была изменена на возврат одного «корневого» дескриптора файла, из которого затем исходят все поиски путей. (На самом деле в WebNFS было два таких корня, другой был «публичным» корнем для URL-адресов nfs://, который не попал в NFSv4.)

Итак, для того, чтобы операция «PUTROOTFH» сработала, необходимобытькорневая файловая система какого-либо рода, поскольку больше невозможно пропускать шаги – все обходы пути представляют собой серию составных операций [PUTROOTFH, LOOKUP, LOOKUP, ..., LOOKUP, OPEN]. Это отражает Plan9's 9p, а также SMBv2/3.

(Все это подразумевает, что в этом стиле экспортированные пути файловой системы становятся относительными к корню, например, ваш /exports/home монтируется как "foo:/home",неткак "foo:/exports/home".)

Отсутствие операции MOUNT(path) также является причиной того, что подразумевается "crossmnt", посколькуне являетсявсе, что осталось смонтировать, это просто «ПРОСМОТР» вниз от корня.

На практике NFSv4 может использовать любой стиль — если экспорт «fsid=0» не определен, ядро ​​Linux (2.6.33 или более поздняя версия)автоматически сгенерирует /для вас виртуальный коренькоторый не содержит ничего, кроме монтирований для ваших обычных экспортированных расположений. (Это также имеет преимущество сохранения идентичных путей монтирования между NFSv3 и NFSv4.) Другими словами, вы действительно можете продолжать использовать свою исходную конфигурацию в стиле v3.

Связанный контент