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

Статья
11/19/2023

Протокол 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 должен знать, какой тип субъекта определен.

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

Доступ и запрет флагов

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

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

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

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

Флаг наследования	Поведение
d	— каталоги под родительским каталогом наследуют ACL — флаг наследования также наследуется
f	— Файлы под родительским каталогом наследуют ACL — Файлы не задают флаг наследования
i	Только наследование; ACL не применяется к текущему каталогу, но должен применять наследование к объектам под каталогом.
n	- Нет распространения наследования После наследования 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, но они не наследуют флаг, так как он может применяться только к acEs каталога.

# 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 . В результате подкаталог очищает флаги наследования для этого субъекта и объектов, созданных подкаталогом, не наследуются от user2ACE.

#  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 () доступа для выполнения действий.

Azure NetApp Files поддерживает настройку административных флагов для acES аудита, однако acEs не работают. Кроме того, в Azure NetApp Files не поддерживаются службы 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 настоятельно рекомендуется использовать при использовании списков управления доступом 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 разрешений, которые можно задать для групп.

Письмо с разрешением	Предоставленное разрешение
r	Чтение файлов и папок с данными и списками
w	Запись данных и создание файлов и папок
a	Добавление данных и создание подкаталогов
x	Выполнение файлов и каталогов обхода
d	Удаление файлов / каталогов
D	Удаление подкаталогов (только каталогов)
t	Чтение атрибутов (GETATTR)
T	Атрибуты записи (SETATTR/chmod)
n	Чтение именованных атрибутов
N	Запись именованных атрибутов
c	Чтение списков управления доступом
C	Запись списков управления доступом
o	Владелец записи (chown)
г	Синхронный ввод-вывод

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

Примеры разрешений 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), но файлы не могут быть созданы, так как разрешен доступ только для чтения. Эта конфигурация иллюстрирует тип гранулярных элементов управления 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
1 — выполнение (x)	Выполнение, чтение атрибутов, чтение списков управления доступом, синхронизация операций ввода-вывода (xtcy)
2 — запись (w)	Запись, добавление данных, атрибуты чтения, атрибуты записи, запись именованных атрибутов, чтение списков управления доступом, синхронизация операций ввода-вывода (watTNcy)
3 — запись и выполнение (wx)	Запись, добавление данных, выполнение, чтение атрибутов, атрибуты записи, именованные атрибуты записи, чтение списков управления доступом, синхронизация операций ввода-вывода (waxtTNcy)
4 — чтение (r)	Чтение, чтение атрибутов, чтение именованных атрибутов, чтение списков управления доступом, синхронизация операций ввода-вывода (rtncy)
5 — чтение и выполнение (rx)	Чтение, выполнение, чтение атрибутов, чтение именованных атрибутов, чтение списков управления доступом, синхронизация операций ввода-вывода (rxtncy)
6 — чтение и запись (rw)	Чтение, запись, добавление данных, атрибуты чтения, атрибуты записи, чтение именованных атрибутов, запись именованных атрибутов, чтение списков управления доступом, синхронизация операций ввода-вывода (rltTnNcy)
7 — чтение и запись и выполнение (rwx)	Полный контроль или все разрешения

Как 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 с помощью списков ACL NFSv4.x. При установке флага наследования списки управления доступом в родительском каталоге могут распространяться по подкаталогам и файлам без дальнейшего взаимодействия. Azure NetApp Files реализует стандартное поведение ACL в зависимости от RFC-7530.

Запретить доступ к aces

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

Сохранение ACL

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

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

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

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

Имена пользователей Windows должны правильно сопоставляться с именами пользователей UNIX для правильного разрешения управления доступом.
В томах стиля безопасности UNIX (где будут применяться списки управления доступом NFSv4.x), если допустимый пользователь UNIX не существует на сервере LDAP для пользователя Windows для сопоставления, то для сопоставления используется пользователь pcuser UNIX по умолчанию (с пользовательским числом 65534).
Файлы, написанные пользователями Windows без допустимого сопоставления пользователей UNIX, принадлежат числовым идентификатором 65534, который соответствует имени пользователя "nfsnobody" или "никто" в клиентах 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 с NFSv4.x ACL

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

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

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

При запуске блока в Azure NetApp Files назначенный владелец может быть изменен. Владение файлами не так важно при использовании списков управления доступом NFSv4.x, как при использовании битов режима, так как списки ACL можно использовать для управления разрешениями таким образом, чтобы базовые понятия владельца или группы или всех пользователей не могли. Chown в Azure NetApp Files может выполняться только как корневой (как корневой или с помощью sudo), так как элементы управления экспортом настроены только для разрешения корневых изменений владения. Так как это управляется правилом политики экспорта по умолчанию в 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 (и корневом каталоге). Удаление системных acEs может нарушить работу приложений, использующих битовые представления в режиме для функциональных возможностей.

Поведение корневого пользователя с помощью ACL NFSv4.x

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

Чтобы настроить скваширование корневых элементов, перейдите в меню политики экспорта в томе, а затем измените "Корневой доступ" на "Off" для правила политики.

Эффект отключения корневого корня доступа к корням сквош для анонимного пользователя 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 можно использовать для детального ограничения корневого доступа.

Поделиться через