Общие сведения о списках управления доступом NFSv4.x в Azure NetApp Files

Протокол NFSv4.x может обеспечить управление доступом в виде списков управления доступом (ACL), которые концептуально похожи на списки управления доступом, используемые в SMB через разрешения WINDOWS NTFS. ACL NFSv4.x состоит из отдельных элементов управления доступом (ACEs), каждый из которых предоставляет директиву управления доступом для сервера.

Каждый ACL NFSv4.x использует формат type:flags:principal:permissions.

• Тип — тип определяемого списка контроля доступа (ACL). Допустимые варианты: Access (A), Deny (D), Audit (U), Alarm (L). Azure NetApp Files поддерживает типы ACL: доступ, запрет и аудит, но типы аудита ACL, хотя и могут быть установлены, в настоящее время не создают журналы аудита.
• Флаги — добавляет дополнительный контекст для ACL. Существует три типа флагов ACE: группирование, наследование и администрирование. Дополнительные сведения о флагах см. в разделе NFSv4.x ACE флаги.
• Субъект — определяет пользователя или группу, которым назначен ACL. Субъект в ACL NFSv4.x использует формат name@ID-DOMAIN-STRING.COM. Дополнительные сведения о принципалах см. раздел NFSv4.x user and group principals.
• Разрешения — определение уровня доступа для субъекта. Разрешения обозначаются одной буквой. Например, "r" предоставляет разрешения на чтение, "w" — разрешения на запись. Полный доступ включает каждое доступное письмо разрешений. Дополнительные сведения см. в разделе разрешений NFSv4.x.

A:g:group1@contoso.com:rwatTnNcCy является примером допустимого ACL, следующего за форматом type:flags:principal:permissions . В примере ACL предоставляется полный доступ к группе group1 в домене идентификатора contoso.com.

Флаги ACE NFSv4.x

Флаг ACE позволяет предоставить дополнительные сведения об ACE в ACL. Например, если группа ACE добавляется в ACL, флаг группы должен использоваться для указания на то, что субъект является группой, а не пользователем. В Linux-средах можно использовать одинаковые имена для пользователя и группы, поэтому флаг гарантирует, что ACE будет соблюдаться, а сервер NFS должен знать, какой именно тип субъекта определяется.

Другие флаги могут использоваться для управления ACE, например, для наследования и административных целей.

Флаги доступа и запрета

Для управления типами ACE используются флаги доступа (A) и запрета (D). Доступ ACE управляет уровнем разрешений на доступ к файлу или папке для субъекта. Запрет ACE явно запрещает субъекту доступ к файлу или папке, даже если задан доступ ACE, который позволит субъекту получить доступ к объекту. Запрещающие ACE всегда имеют преимущество над ACE доступа. Как правило, избегайте использования ACE отклонения, так как списки управления доступом (ACL) NFSv4.x соответствуют модели «запрещать по умолчанию», что означает: если ACL не добавлены, то отклонение применяется по умолчанию. Запрет ACEs может создавать ненужные осложнения в управлении ACL.

Флаги наследования

Флаги наследования управляют поведением списков управления доступом к файлам, созданным под родительским каталогом с набором флагов наследования. При установке флага наследования файлы и каталоги наследуют списки управления доступом из родительской папки. Флаги наследования можно применять только к каталогам, поэтому при создании подкаталога он наследует флаг. Файлы, созданные под родительским каталогом с флагом наследования, наследуют списки управления доступом, но не флаги наследования.

В следующей таблице описываются доступные флаги наследования и их поведение.

Примеры ACL NFSv4.x

В следующем примере представлено три различных ACEs с отдельными флагами наследования.

• (di) — каталог наследуется только
• (fi) — только наследование файла
• (пии) — наследуется как файл, так и каталог

# nfs4_getfacl acl-dir

# file: acl-dir/
A:di:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fdi:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

User1 содержит только каталог, наследующий ACL. В подкаталоге, созданном под родительским каталогом, ACL наследуется, но в файле под родительским каталогом наследование не происходит.

# nfs4_getfacl acl-dir/inherit-dir

# file: acl-dir/inherit-dir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# nfs4_getfacl acl-dir/inherit-file

# file: acl-dir/inherit-file 
                       << ACL missing
A::user2@CONTOSO.COM:rwaxtTnNcCy
A::user3@CONTOSO.COM:rwaxtTnNcCy
A::OWNER@:rwatTnNcCy
A:g:GROUP@:rtncy
A::EVERYONE@:rtncy

User2 имеет флаг наследуемого файла и каталога. В результате как файлы, так и каталоги, находящиеся в подкаталоге с этой записью ACE, наследуют ACL, но файлы не наследуют флаг.

# nfs4_getfacl acl-dir/inherit-dir

# file: acl-dir/inherit-dir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# nfs4_getfacl acl-dir/inherit-file

# file: acl-dir/inherit-file
A::user2@CONTOSO.COM:rwaxtTnNcCy << no flag
A::user3@CONTOSO.COM:rwaxtTnNcCy
A::OWNER@:rwatTnNcCy
A:g:GROUP@:rtncy
A::EVERYONE@:rtncy

User3 имеет только флаг унаследования файла. В результате только файлы под каталогом с этой записью ACE наследуют ACL, но они не наследуют флаг, так как он может применяться только к записям ACE каталогов.

# nfs4_getfacl acl-dir/inherit-dir

# file: acl-dir/inherit-dir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# nfs4_getfacl acl-dir/inherit-file

# file: acl-dir/inherit-file
A::user2@CONTOSO.COM:rwaxtTnNcCy
A::user3@CONTOSO.COM:rwaxtTnNcCy << no flag
A::OWNER@:rwatTnNcCy
A:g:GROUP@:rtncy
A::EVERYONE@:rtncy

Если флаг "без распространения" (n) установлен в ACL, флаги очищаются при последующих созданиях каталогов под родительским элементом. В следующем примере у user2 установлен флаг n. В результате подкаталог отменяет флаги наследования для этого субъекта, и объекты, созданные в этом подкаталоге, не наследуют ACE из user2.

#  nfs4_getfacl /mnt/acl-dir

# file: /mnt/acl-dir
A:di:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fdn:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

#  nfs4_getfacl inherit-dir/

# file: inherit-dir/
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A::user2@CONTOSO.COM:rwaDxtTnNcCy << flag cleared
A:fd:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# mkdir subdir
# nfs4_getfacl subdir

# file: subdir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
<< ACL not inherited
A:fd:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

Наследуемые флаги — это способ упрощения управления списками управления доступом NFSv4.x, который избавляет вас от необходимости явно задавать ACL всякий раз, когда это необходимо.

Административные флаги

Административные флаги в списках управления доступом NFSv4.x — это специальные флаги, используемые только с типами списков ACL для аудита и оповещения. Эти флаги определяют попытки либо успешного (S), либо неудачного (F) доступа при выполнении действий.

Этот аудиторский список ACL является примером, где user1 проверяется на предмет неудачных попыток доступа для любого уровня разрешений: U:F:user1@contoso.com:rwatTnNcCy.

Azure NetApp Files поддерживает только установку административных флагов для записей контроля доступа (ACE) аудита. Для журналов доступа к файлам необходимы записи аудита контроля доступа. В Azure NetApp Files не поддерживаются Alarm ACEs.

Принципы пользователей и групп NFSv4.x

При использовании ACL NFSv4.x субъекты-пользователи и группы определяют определенные объекты, к которым должен применяться ACE. Руководители обычно следуют формату name@ID-DOMAIN-STRING.COM. Часть имени субъекта может обозначать пользователя или группу, но эти пользователь или группа должны быть определяемыми в Azure NetApp Files через подключение к серверу LDAP при указании домена идентификатора NFSv4.x. Если name@domain не может быть разрешён через Azure NetApp Files, операция ACL проваливается с ошибкой "неверный аргумент".

# nfs4_setfacl -a A::noexist@CONTOSO.COM:rwaxtTnNcCy inherit-file
Failed setxattr operation: Invalid argument

Вы можете проверить в Azure NetApp Files, можно ли разрешить имя с помощью списка идентификаторов группы LDAP. Перейдите в раздел "Поддержка и устранение неполадок ", а затем список идентификаторов группы LDAP.

Локальный доступ пользователей и групп с помощью ACL NFSv4.x

Локальные пользователи и группы также можно использовать в ACL NFSv4.x, если в ACL указан только числовой идентификатор. Имена пользователей или числовые идентификаторы с указанным идентификатором домена не работают.

Например:

# nfs4_setfacl -a A:fdg:3003:rwaxtTnNcCy NFSACL
# nfs4_getfacl NFSACL/
A:fdg:3003:rwaxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rwaDxtTnNcy
A::EVERYONE@:rwaDxtTnNcy

# nfs4_setfacl -a A:fdg:3003@CONTOSO.COM:rwaxtTnNcCy NFSACL
Failed setxattr operation: Invalid argument

# nfs4_setfacl -a A:fdg:users:rwaxtTnNcCy NFSACL
Failed setxattr operation: Invalid argument

Если задан локальный пользователь или группа ACL, любой пользователь или группа, соответствующий числовому идентификатору в ACL, получает доступ к объекту. Для списков контроля доступа локальных групп пользователь передает свои членства в группах в службу Azure NetApp Files. Если числовый идентификатор группы с доступом к файлу с помощью запроса пользователя отображается на сервере Azure NetApp Files NFS, то доступ разрешен в рамках ACL.

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

Предостережения:

• Использование локальных пользователей и групп для списков управления доступом означает, что каждый клиент, обращающийся к файлам и папкам, должен иметь соответствующие идентификаторы пользователей и групп.
• При использовании числового идентификатора для ACL Azure NetApp Files неявно доверяет тому, что входящий запрос действителен, и что пользователь, запрашивающий доступ, является тем, за кого себя выдает, и действительно состоит в тех группах, в которых утверждает состоять. Числовой пользователь или группа может быть подделан, если неправомерный субъект знает числовой идентификатор и может получить доступ к сети с помощью клиента с возможностью локального создания пользователей и групп.
• Если пользователь является членом более 16 групп, то любая группа после шестнадцатой группы (в буквенно-цифровом порядке) запрещена доступ к файлу или папке, если не используется протокол LDAP и расширенная поддержка групп.
• Строки LDAP и полные строки имен в формате name@domain настоятельно рекомендуется использовать с ACL NFSv4.x для улучшения управляемости и безопасности. Централизованно управляемый репозиторий пользователей и групп проще поддерживать и труднее спуфингировать, что делает нежелательный доступ пользователей менее вероятным.

Домен идентификатора NFSv4.x

Домен идентификатора является важным компонентом субъекта, где домен идентификатора должен совпадать как на клиенте, так и в Azure NetApp Files для имен пользователей и групп (в частности, root), чтобы правильно отображаться в правах владения файлами и папками.

Azure NetApp Files по умолчанию устанавливает домен идентификатора NFSv4.x в соответствии с настройками домена DNS для тома. Клиенты NFS также по умолчанию используют домен DNS для домена идентификатора NFSv4.x. Если dns-домен клиента отличается от домена DNS Azure NetApp Files, возникает несоответствие. При перечислении разрешений на файлы с такими командами, как ls, пользователи и группы отображаются как "никто".

Если несоответствие домена происходит между клиентом NFS и Azure NetApp Files, проверьте журналы клиентов на наличие ошибок, аналогичных следующим:

August 19 13:14:29 nfsidmap[17481]: nss_getpwnam: name 'root@microsoft.com' does not map into domain ‘CONTOSO.COM'

Домен идентификатора клиента NFS можно переопределить с помощью параметра /etc/idmapd.conf файла "Домен". Например: Domain = CONTOSO.COM.

Azure NetApp Files также позволяет изменить домен идентификатора NFSv4.1. Дополнительные сведения см. в руководстве по настройке домена NFSv4.1 для Azure NetApp Files.

Разрешения NFSv4.x

Разрешения NFSv4.x — это способ управления уровнем доступа определенного пользователя или участника группы в файле или папке. Права доступа в NFSv3 допускают только чтение, запись и выполнение (rwx), однако NFSv4.x предлагает множество других детализированных механизмов контроля доступа, что является улучшением по сравнению с режимами NFSv3.

Для пользователей можно задать 13 разрешений и 14 разрешений, которые можно задать для групп.

Если заданы разрешения доступа, пользователь или субъект группы соответствует этим назначенным правам.

Примеры разрешений NFSv4.x

В следующих примерах показано, как разные разрешения работают с различными сценариями конфигурации.

Пользователь с доступом на чтение (только r)

При доступе только для чтения пользователь может считывать атрибуты и данные, но доступ на запись (данные, атрибуты, владелец) запрещен.

A::user1@CONTOSO.COM:r

sh-4.2$ ls -la
total 12
drwxr-xr-x 3 root root 4096 Jul 12 12:41 .
drwxr-xr-x 3 root root 4096 Jul 12 12:09 ..
-rw-r--r-- 1 root root    0 Jul 12 12:41 file
drwxr-xr-x 2 root root 4096 Jul 12 12:31 subdir
sh-4.2$ touch user1-file
touch: can't touch ‘user1-file’: Permission denied
sh-4.2$ chown user1 file
chown: changing ownership of ‘file’: Operation not permitted
sh-4.2$ nfs4_setfacl -e /mnt/acl-dir/inherit-dir
Failed setxattr operation: Permission denied
sh-4.2$ rm file
rm: remove write-protected regular empty file ‘file’? y
rm: can't remove ‘file’: Permission denied
sh-4.2$ cat file
Test text

Пользователь с доступом на чтение (r) и атрибутами записи (T)

В этом примере разрешения на файл можно изменить из-за разрешения на запись атрибутов (T), но файлы не могут быть созданы, так как разрешен доступ только для чтения. Эта конфигурация иллюстрирует тип подробных средств управления, которые могут обеспечить ACL NFSv4.x.

A::user1@CONTOSO.COM:rT

sh-4.2$ touch user1-file
touch: can't touch ‘user1-file’: Permission denied
sh-4.2$ ls -la
total 60
drwxr-xr-x  3 root     root    4096 Jul 12 16:23 .
drwxr-xr-x 19 root     root   49152 Jul 11 09:56 ..
-rw-r--r--  1 root     root      10 Jul 12 16:22 file
drwxr-xr-x  3 root     root    4096 Jul 12 12:41 inherit-dir
-rw-r--r--  1 user1    group1     0 Jul 12 16:23 user1-file
sh-4.2$ chmod 777 user1-file
sh-4.2$ ls -la
total 60
drwxr-xr-x  3 root     root    4096 Jul 12 16:41 .
drwxr-xr-x 19 root     root   49152 Jul 11 09:56 ..
drwxr-xr-x  3 root     root    4096 Jul 12 12:41 inherit-dir
-rwxrwxrwx  1 user1    group1     0 Jul 12 16:23 user1-file
sh-4.2$ rm user1-file
rm: can't remove ‘user1-file’: Permission denied

Преобразование режимных битов в разрешения ACL NFSv4.x

При запуске chmod объекта с назначенными списками управления доступом NFSv4.x ряд системных списков управления доступом обновляется с новыми разрешениями. Например, если для разрешений задано значение 755, то системные файлы ACL обновляются. В следующей таблице показано, что каждое числовое значение в бите режима преобразуется в разрешения ACL NFSv4.

См. разрешения NFSv4.x в таблице, в которой представлены все разрешения.

Как NFSv4.x ACL работают с Azure NetApp Files

Azure NetApp Files поддерживает списки управления доступом NFSv4.x встроенно, если в томе включен доступ через NFSv4.1. Нет необходимости включать что-либо в томе для поддержки ACL, но для более эффективной работы списков контроля доступа NFSv4.1 требуется сервер LDAP с пользователями и группами UNIX, чтобы убедиться, что Azure NetApp Files может безопасно разрешать имена субъектов, заданные в списках контроля доступа. Локальные пользователи могут использоваться с списками управления доступом NFSv4.x, но они не обеспечивают тот же уровень безопасности, что и списки управления доступом, используемые с сервером LDAP.

Следует учитывать аспекты функциональности ACL в Azure NetApp Files.

Наследование ACL

В Azure NetApp Files флаги наследования ACL можно использовать для упрощения управления списками ACL в NFSv4.x. При установке флага наследования списки управления доступом в родительском каталоге могут распространяться по подкаталогам и файлам без дальнейшего взаимодействия. Azure NetApp Files реализует стандартное поведение наследования ACL в соответствии с RFC-7530.

Запретить ACEs

Элементы управления доступом DENY (ACEs) в Azure NetApp Files используются для явного ограничения доступа пользователя или группы к файлу или папке. Подмножество разрешений можно определить для предоставления детализированных элементов управления запретом ACE. Они работают в стандартных методах, упомянутых в RFC-7530.

Сохранение списка контроля доступа (ACL)

При выполнении команды chmod для файла или папки в Azure NetApp Files все существующие элементы управления доступом (ACEs) сохраняются в ACL, кроме системных ACEs (OWNER@, GROUP@, EVERYONE@). Эти разрешения ACE изменяются в соответствии с битами числового режима, определяемыми командой chmod. Можно изменить только ACE, которые изменены или удалены вручную с помощью команды nfs4_setfacl.

Поведение ACL NFSv4.x в средах с двумя протоколами

Двойной протокол означает использование SMB и NFS в одном томе файлового ресурса Azure NetApp Files. Управление доступом с двумя протоколами зависит от стиля безопасности, который используется для тома, но сопоставление имен пользователей Windows и UNIX, успешно сопоставляемых друг с другом, обеспечивает одинаковые разрешения на доступ к данным.

Если списки управления доступом NFSv4.x используются в томах стиля безопасности UNIX, то при использовании томов с двумя протоколами и доступе к данным с клиентов SMB наблюдается следующее поведение.

• Имена пользователей Windows должны правильно сопоставляться с именами пользователей UNIX для правильного разрешения управления доступом.
• В томах с UNIX-стилем безопасности (где применяются списки управления доступом NFSv4.x), если в сервере LDAP нет подходящего пользователя UNIX, с которым можно сопоставить пользователя Windows, то используется пользователь UNIX по умолчанию с именем pcuser (с uid 65534) для сопоставления.
• Файлы, созданные пользователями Windows без корректного сопоставления с пользователями UNIX, отображаются как принадлежащие с числовым идентификатором 65534, который соответствует именам пользователей "nfsnobody" или "nobody" в Linux клиентах при подключениях через NFS. Это отличается от цифрового идентификатора 99, который обычно ассоциируется с проблемами домена NFSv4.x. Чтобы проверить используемый числовой идентификатор, используйте ls -lan команду.
• Файлы с неправильными владельцами не дают ожидаемых результатов от разрешений режима UNIX или списков управления доступом NFSv4.x.
• Списки управления доступом NFSv4.x управляются с помощью клиентов NFS. Клиенты SMB не могут ни просматривать, ни управлять списками управления доступом NFSv4.x.

Влияние Umask с NFSv4.x ACL

Списки управления доступом NFSv4 предоставляют возможность поддерживать наследование ACL. Наследование ACL означает, что файлы или папки, созданные в рамках объектов с установленными списками управления доступом NFSv4, могут наследовать списки управления доступом на основе конфигурации флага наследования ACL.

Umask используется для управления уровнем разрешений, на котором создаются файлы и папки в каталоге. По умолчанию Azure NetApp Files позволяет umask переопределять наследуемые списки управления доступом, что является ожидаемым поведением в соответствии с RFC-7530.

Дополнительные сведения см. в статье umask.

Поведение chmod/chown с ACL NFSv4.x

В Azure NetApp Files вы можете использовать команды изменения владельца (chown) и изменения режима доступа (chmod) для управления разрешениями файлов и каталогов в NFSv3 и NFSv4.x.

При использовании списков управления доступом NFSv4.x более детализированное управление доступом к файлам и папкам уменьшает потребность в командах chmod. Chown по-прежнему необходим, так как списки управления доступом (ACL) NFSv4.x не назначают права владения.

При запуске команды chmod в Azure NetApp Files в файлах и папках с установленными списками управления доступом NFSv4.x биты режима изменяются на объекте. Кроме того, набор системных ACE изменяется, чтобы отразить эти биты режима. Если системы ACE удаляются, то биты режима очищаются. Примеры и более полное описание см. в разделе по системным acEs ниже.

При использовании команды chown в Azure NetApp Files назначенный владелец может быть изменён. Владение файлами не является столь критичным при использовании списков управления доступом NFSv4.x, как при использовании битов режима, так как списки ACL позволяют управлять разрешениями более гибко, чем базовые понятия владельца, группы и всех пользователей. Chown в Azure NetApp Files может выполняться только от имени root (либо напрямую, либо с использованием sudo), так как элементы управления экспортом настроены так, чтобы позволять изменения владения только root. Так как это управляется правилом политики экспорта по умолчанию в Azure NetApp Files, записи ACL NFSv4.x, разрешающие изменения владения, не применяются.

# su user1
# chown user1 testdir
chown: changing ownership of ‘testdir’: Operation not permitted
# sudo chown user1 testdir
# ls -la | grep testdir
-rw-r--r--  1 user1    root     0 Jul 12 16:23 testdir

Правило политики экспорта тома можно отредактировать, чтобы изменить это поведение. В меню политики экспорта тома измените режим Chown на "неограниченный".

После изменения владение может быть изменено пользователями, кроме root, при наличии соответствующих прав доступа. Для этого требуется разрешение "Взятие на себя владельческого права" NFSv4.x ACL (обозначенное буквой "o"). Также можно изменить владение, если пользователь, изменяющий владение, в настоящее время владеет файлом или папкой.

A::user1@contoso.com:rwatTnNcCy  << no ownership flag (o)

user1@ubuntu:/mnt/testdir$ chown user1 newfile3
chown: changing ownership of 'newfile3': Permission denied

A::user1@contoso.com:rwatTnNcCoy  << with ownership flag (o)

user1@ubuntu:/mnt/testdir$ chown user1 newfile3
user1@ubuntu:/mnt/testdir$ ls -la
total 8
drwxrwxrwx 2 user2 root       4096 Jul 14 16:31 .
drwxrwxrwx 5 root  root       4096 Jul 13 13:46 ..
-rw-r--r-- 1 user1 root          0 Jul 14 15:45 newfile
-rw-r--r-- 1 root  root          0 Jul 14 15:52 newfile2
-rw-r--r-- 1 user1 4294967294    0 Jul 14 16:31 newfile3

Системные ACEs

В каждом списке ACL есть ряд системных ACEs: OWNER@, GROUP@, EVERYONE@. Например:

A::OWNER@:rwaxtTnNcCy
A:g:GROUP@:rwaxtTnNcy
A::EVERYONE@:rwaxtTnNcy

Эти ACEs соответствуют битам разрешений в классическом режиме, которые вы видите в NFSv3 и напрямую с ними связаны. При запуске chmod в объекте эти системные списки управления доступом изменяются, чтобы отразить эти разрешения.

# nfs4_getfacl user1-file

# file: user1-file
A::user1@CONTOSO.COM:rT
A::OWNER@:rwaxtTnNcCy
A:g:GROUP@:rwaxtTnNcy
A::EVERYONE@:rwaxtTnNcy

# chmod 755 user1-file

# nfs4_getfacl user1-file

# file: user1-file
A::OWNER@:rwaxtTnNcCy
A:g:GROUP@:rxtncy

Если эти системные ACEs удалены, то представление разрешений изменится таким образом, что биты обычного режима (rwx) отображаются как дефисы.

# nfs4_setfacl -x A::OWNER@:rwaxtTnNcCy user1-file
# nfs4_setfacl -x A:g:GROUP@:rxtncy user1-file
# nfs4_setfacl -x A::EVERYONE@:rxtncy user1-file
# ls -la | grep user1-file
----------  1 user1 group1     0 Jul 12 16:23 user1-file

Удаление системных acEs — это способ дальнейшего защиты файлов и папок, так как доступ к объекту могут получить только пользователи и субъекты группы в ACL (и корневом каталоге). Удаление системных ACE может нарушить работу приложений, полагающихся на просмотр режимов с битами.

Поведение корневого пользователя при работе с NFSv4.x списками контроля доступа (ACL)

Корневой доступ с ACLs NFSv4.x не может быть ограничен, если права root пользователя не урезаны. Root squashing — это правило экспорта, где пользователь root сопоставляется с анонимным пользователем для ограничения доступа. Корневой доступ можно настроить из меню политики экспорта тома, изменив правило политики корневого доступа на отключенный.

Чтобы настроить функцию понижения прав root, перейдите в меню политики экспорта для тома, а затем измените параметр "Корневой доступ" на "выключено" в правиле политики.

Эффект отключения корневого корня доступа к корням сквош для анонимного пользователя nfsnobody:65534. Затем корневой доступ не может изменить владение.

root@ubuntu:/mnt/testdir# touch newfile3
root@ubuntu:/mnt/testdir# ls -la
total 8
drwxrwxrwx 2 user2  root       4096 Jul 14 16:31 .
drwxrwxrwx 5 root   root       4096 Jul 13 13:46 ..
-rw-r--r-- 1 user1  root          0 Jul 14 15:45 newfile
-rw-r--r-- 1 root   root          0 Jul 14 15:52 newfile2
-rw-r--r-- 1 nobody 4294967294    0 Jul 14 16:31 newfile3
root@ubuntu:/mnt/testdir# ls -lan
total 8
drwxrwxrwx 2  1002          0 4096 Jul 14 16:31 .
drwxrwxrwx 5     0          0 4096 Jul 13 13:46 ..
-rw-r--r-- 1  1001          0    0 Jul 14 15:45 newfile
-rw-r--r-- 1     0          0    0 Jul 14 15:52 newfile2
-rw-r--r-- 1 65534 4294967294    0 Jul 14 16:31 newfile3
root@ubuntu:/mnt/testdir# chown root newfile3
chown: changing ownership of 'newfile3': Operation not permitted

Альтернативно, в средах с двумя протоколами ACL NTFS можно использовать для гранулярного ограничения доступа к root.

Следующие шаги

• Настройка клиентов NFS
• Настройка списков управления доступом на томах NFSv4.1