Azure NetApp Files의 NFSv4.x 액세스 제어 목록 이해

NFSv4.x 프로토콜은 ACL(액세스 제어 목록)형식으로 액세스 제어를 제공할 수 있습니다. 이는 개념적으로 Windows NTFS 권한을 통해 SMB에서 사용되는 ACL과 유사합니다. NFSv4.x ACL은 개별 ACE(Access Control Entries)로 구성됩니다. 각 ACE는 서버에 대한 액세스 제어 지시문을 제공합니다.

각 NFSv4.x ACL은 type:flags:principal:permissions 형식으로 만들어집니다.

• 유형 – 정의되는 ACL의 유형입니다. 유효한 선택 항목으로는 액세스(A), 거부(D), 감사(U), 경보(L)가 있습니다. Azure NetApp Files는 액세스, 거부 및 감사 ACL 유형을 지원하지만, 감사 ACL은 설정만 할 수 있고 현재 감사 로그를 생성하지는 않습니다.
• 플래그 – ACL에 대한 추가 컨텍스트를 추가합니다. ACE 플래그에는 그룹, 상속, 관리라는 세 가지 종류가 있습니다. 플래그에 대한 자세한 내용은 NFSv4.x ACE 플래그를 참조하세요.
• 보안 주체 – ACL에 할당되는 사용자 또는 그룹을 정의합니다. NFSv4.x ACL의 보안 주체는 name@ID-DOMAIN-STRING.COM 형식을 사용합니다. 보안 주체에 대한 자세한 내용은 NFSv4.x 사용자 및 그룹 보안 주체를 참조하세요.
• 사용 권한 - 여기에서 보안 주체에 대한 액세스 수준을 정의합니다. 각 사용 권한은 하나의 문자로 지정됩니다(예: 읽기는 "r", 쓰기는 "w" 등등으로 지정). 모든 권한은 사용 가능한 각 사용 권한 문자를 통합합니다. 자세한 내용은 NFSv4.x 권한을 참조하세요.

A:g:group1@contoso.com:rwatTnNcCy는 type:flags:principal:permissions 형식을 따르는 유효한 ACL의 예입니다. 예시한 ACL은 contoso.com ID 도메인의 group1 그룹에 모든 권한을 부여합니다.

NFSv4.x ACE 플래그

ACE 플래그는 ACL의 ACE에 대해 더 자세한 정보를 제공하는 데 도움이 됩니다. 예를 들어 그룹 ACE가 ACL에 추가되면 그룹 플래그를 사용하여 보안 주체가 사용자가 아니라 그룹임을 지정해야 합니다. Linux 환경에서는 동일한 사용자와 그룹 이름을 포함할 수 있으므로 이 플래그를 사용하면 ACE가 적용되며 NFS 서버는 어떤 보안 주체 유형이 정의되는지 알아야 합니다.

상속 및 관리 플래그 등 다른 플래그를 사용하여 ACE를 제어할 수 있습니다.

액세스 및 거부 플래그

액세스(A) 및 거부(D) 플래그는 보안 ACE 유형을 제어하는 데 사용됩니다. 액세스 ACE는 파일 또는 폴더에 대한 보안 주체의 액세스 권한 수준을 제어합니다. 거부 ACE는 보안 주체가 개체에 액세스할 수 있는 액세스 ACE가 설정된 경우에도 보안 주체가 파일 또는 폴더에 액세스하는 것을 명시적으로 금지합니다. 거부 ACE는 항상 액세스 ACE를 재정의합니다. 일반적으로 NFSv4.x ACL은 "기본 거부" 모델을 따르므로 거부 ACL을 사용하지 마세요. 즉, ACL이 추가되지 않으면 거부는 암시적입니다. 거부 ACE는 ACL 관리에서 불필요한 복잡성을 야기할 수 있습니다.

상속 플래그

상속 플래그는 상속 플래그가 설정된 부모 디렉터리 아래에 생성된 파일에서 ACL이 동작하는 방식을 제어합니다. 상속 플래그가 설정되면 파일 및/또는 디렉터리가 부모 폴더에서 ACL을 상속합니다. 상속 플래그는 디렉터리에만 적용할 수 있으므로 하위 디렉터리를 만들 때 플래그를 상속합니다. 상속 플래그가 있는 부모 디렉터리 아래에서 만든 파일은 ACL을 상속하지만 상속 플래그는 상속하지 않습니다.

다음 표에서는 사용 가능한 상속 플래그와 해당 동작에 대해 설명합니다.

NFSv4.x ACL의 예

다음 예에서는 고유한 상속 플래그가 있는 세 가지 다른 ACE가 있습니다.

• 디렉터리 상속만(di)
• 파일 상속만(fi)
• 파일 및 디렉터리 상속 모두(fdi)

# 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이 상속되지만 부모 아래의 파일에서는 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

ACL에서 "no-propogate"(n) 플래그를 설정하면 이후에 부모 아래에 디렉터리를 만들 때 플래그가 지워집니다. 다음 예에서는 user2에 n 플래그가 설정됩니다. 그 결과, 하위 디렉터리는 해당 보안 주체의 상속 플래그를 지우고 해당 하위 디렉터리 아래에 만든 개체는 user2로부터 ACE를 상속하지 않습니다.

#  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을 보다 쉽게 관리할 수 있으므로 필요할 때마다 ACL을 명시적으로 설정하지 않아도 됩니다.

관리 플래그

NFSv4.x ACL의 관리 플래그는 감사 및 경보 ACL 유형에만 사용되는 특수 플래그입니다. 이러한 플래그는 수행할 작업에 대한 성공(S) 또는 실패(F) 액세스 시도를 정의합니다.

Azure NetApp Files는 감사 ACE에 대한 관리 플래그 설정을 지원하지만 ACE가 작동하지는 않습니다. 또한 경보 ACE는 Azure NetApp Files에서 지원되지 않습니다.

NFSv4.x 사용자 및 그룹 보안 주체

NFSv4.x ACL을 사용하면 사용자 및 그룹 보안 주체가 ACE가 적용해야 하는 특정 개체를 정의합니다. 보안 주체는 일반적으로 name@ID-DOMAIN-STRING.COM의 형식을 따릅니다. 보안 주체의 "이름" 부분은 사용자 또는 그룹일 수 있지만 해당 사용자 또는 그룹은 NFSv4.x ID 도메인을 지정할 때 LDAP 서버 연결을 통해 Azure NetApp Files에서 확인할 수 있어야 합니다. Azure NetApp Files에서 name@domain 확인할 수 없는 경우 "잘못된 인수" 오류와 함께 ACL 작업이 실패합니다.

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

LDAP 그룹 ID 목록을 사용하여 이름을 확인할 수 있는지 Azure NetApp Files 내에서 확인할 수 있습니다. 지원 + 문제 해결로 이동한 다음, LDAP 그룹 ID 목록으로 이동합니다.

NFSv4.x ACL을 통한 로컬 사용자 및 그룹 액세스

ACL에 숫자 ID만 지정된 경우 NFSv4.x ACL에서도 로컬 사용자 및 그룹을 사용할 수 있습니다. 도메인 ID가 지정된 사용자 이름 또는 숫자 ID는 실패합니다.

예를 들면 다음과 같습니다.

# 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의 숫자 ID에 해당하는 모든 사용자 또는 그룹이 개체에 대한 액세스 권한을 받습니다. 로컬 그룹 ACL의 경우 사용자가 해당 그룹 구성원 자격을 Azure NetApp Files에 전달합니다. 사용자의 요청을 통해 파일에 액세스할 수 있는 그룹의 숫자 ID가 Azure NetApp Files NFS 서버에 표시되는 경우 ACL에 따라 액세스가 허용됩니다.

클라이언트에서 서버로 전달된 자격 증명은 아래와 같이 패킷 캡처를 통해 볼 수 있습니다.

주의 사항:

• ACL에 로컬 사용자 및 그룹을 사용하면 파일/폴더에 액세스하는 모든 클라이언트에 일치하는 사용자 및 그룹 ID가 있어야 합니다.
• ACL에 숫자 ID를 사용하는 경우 Azure NetApp Files는 들어오는 요청이 유효하고 액세스를 요청하는 사용자가 스스로 말하는 당사자가 맞고 구성원이라고 주장하는 그룹의 구성원임을 암시적으로 신뢰합니다. 잘못된 행위자가 숫자 ID를 알고 있고 로컬로 사용자 및 그룹을 만들 수 있는 클라이언트를 사용하여 네트워크에 액세스할 수 있는 경우 사용자 또는 그룹 숫자를 스푸핑할 수 있습니다.
• 사용자가 16개 이상의 그룹의 구성원인 경우 LDAP 및 확장된 그룹 지원을 사용하지 않는 한 16번째 그룹(영숫자 순서)의 모든 그룹은 파일 또는 폴더에 대한 액세스가 거부됩니다.
• NFSv4.x ACL을 사용하는 경우 관리 효율성과 보안을 높이기 위해 LDAP 및 전체 name@domain 이름 문자열을 사용할 것을 적극 권장합니다. 중앙에서 관리되는 사용자 및 그룹 리포지토리는 유지 관리는 더 쉽고 스푸핑하기는 더 어렵기 때문에 원치 않는 사용자가 액세스할 가능성이 줄어듭니다.

NFSv4.x ID 도메인

ID 도메인은 보안 주체의 중요한 구성 요소입니다. 사용자 및 그룹 이름(특히, 루트)이 파일/폴더 소유권에 제대로 표시되려면 클라이언트와 Azure NetApp Files 내에서 ID 도메인이 일치해야 하기 때문입니다.

Azure NetApp Files는 기본적으로 NFSv4.x ID 도메인을 볼륨에 대한 DNS 도메인 설정으로 설정됩니다. 또한 NFS 클라이언트는 기본적으로 NFSv4.x ID 도메인에 대한 DNS 도메인으로 설정됩니다. 클라이언트의 DNS 도메인이 Azure NetApp Files DNS 도메인과 다른 경우 불일치가 발생합니다. ls와 같은 명령을 사용하여 파일 권한을 나열하면 사용자/그룹이 "nobody"로 표시됩니다.

NFS 클라이언트와 Azure NetApp Files 간에 도메인 불일치가 발생하면 클라이언트 로그에서 다음과 유사한 오류가 있는지 확인합니다.

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

/etc/idmapd.conf 파일의 "도메인" 설정을 사용하여 NFS 클라이언트의 ID 도메인을 재정의할 수 있습니다. 예: Domain = CONTOSO.COM

또한 Azure NetApp Files를 사용하면 NFSv4.1 ID 도메인을 변경할 수 있습니다. 자세한 내용은 방법: Azure NetApp Files에 대한 NFSv4.1 ID 도메인 구성을 참조하세요.

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) 권한으로 인해 파일에 대한 사용 권한을 변경할 수 있지만, 읽기 권한만 허용되므로 파일을 만들 수는 없습니다. 이 구성은 NFSv4.x ACL이 제공할 수 있는 세분화된 제어 유형을 보여 줍니다.

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

모드 비트를 NFSv4.x ACL 사용 권한으로 변환

chmod가 NFSv4.x ACL이 할당된 개체를 실행하면 일련의 시스템 ACL이 새 사용 권한으로 업데이트됩니다. 예를 들어 사용 권한이 755로 설정된 경우 시스템 ACL 파일이 업데이트됩니다. 다음 표에서는 모드 비트의 각 숫자 값이 NFSv4 ACL 사용 권한으로 어떻게 변환되는지 보여 줍니다.

모든 사용 권한이 설명된 표를 보려면 NFSv4.x 사용 권한을 참조하세요.

NFSv4.x ACL이 Azure NetApp Files에서 작동하는 방법

볼륨에 NFSv4.1이 액세스할 수 있도록 설정된 경우 Azure NetApp Files에서 기본적으로 NFSv4.x ACL을 지원합니다. 볼륨에서 ACL 지원을 위해 사용할 수 있는 것이 없지만 NFSv4.1 ACL이 가장 잘 작동하기 위해서는 Azure NetApp Files가 ACL에 설정된 보안 주체를 안전하게 확인할 수 있도록 UNIX 사용자 및 그룹이 있는 LDAP 서버가 필요합니다. 로컬 사용자는 NFSv4.x ACL과 함께 사용할 수 있지만 LDAP 서버에서 사용되는 ACL과 동일한 수준의 보안을 제공하지는 않습니다.

Azure NetApp Files의 ACL 기능에 유의해야 할 고려 사항이 있습니다.

ACL 상속

Azure NetApp Files에서 ACL 상속 플래그를 사용하여 NFSv4.x ACL로 ACL 관리를 간소화할 수 있습니다. 상속 플래그가 설정되면 부모 디렉터리의 ACL은 추가 상호 작용 없이 하위 디렉터리와 파일로 전파할 수 있습니다. Azure NetApp Files는 RFC-7530에 따라 표준 ACL 상속 동작을 구현합니다.

거부 ACE

Azure NetApp Files의 거부 ACE는 사용자 또는 그룹이 파일 또는 폴더에 액세스하지 못하도록 명시적으로 제한하는 데 사용됩니다. 사용 권한의 하위 집합을 정의하여 거부 ACE에 대한 세분화된 제어를 제공할 수 있습니다. RFC-7530에 언급된 표준 메서드로 작동합니다.

ACL 유지

Azure NetApp Files의 파일 또는 폴더에서 chmod를 수행하는 경우 시스템 ACE(OWNER@, GROUP@, EVERYONE@) 이외의 ACL에 기존의 모든 ACE가 유지됩니다. 이러한 ACE 권한은 chmod 명령으로 정의된 숫자 모드 비트에 의해 정의된 대로 수정됩니다. nfs4_setfacl 명령을 통해 수동으로 수정되거나 제거되는 ACE만 변경할 수 있습니다.

이중 프로토콜 환경의 NFSv4.x ACL 동작

이중 프로토콜은 동일한 Azure NetApp Files 볼륨에서 SMB와 NFS를 모두 사용하는 것을 의미합니다. 이중 프로토콜 액세스 제어는 볼륨에서 사용하는 보안 스타일에 따라 결정되지만 사용자 이름 매핑을 사용하면 서로 성공적으로 매핑된 Windows 사용자와 UNIX 사용자가 데이터에 대해 동일한 액세스 권한을 갖게 됩니다.

UNIX 보안 스타일 볼륨에서 NFSv4.x ACL을 사용 중인 경우 이중 프로토콜 볼륨을 사용하고 있고 SMB 클라이언트에서 데이터에 액세스하면 다음 동작을 볼 수 있습니다.

• Windows 사용자 이름은 적절한 액세스 제어 확인을 위해 UNIX 사용자 이름에 제대로 매핑해야 합니다.
• UNIX 보안 스타일 볼륨(NFSv4.x ACL이 적용되는 경우)에서 Windows 사용자의 LDAP 서버에 매핑할 유효한 UNIX 사용자가 없으면 pcuser(uid 숫자 65534 사용)라는 기본 UNIX 사용자가 매핑에 사용됩니다.
• 유효한 UNIX 사용자 매핑이 없는 Windows 사용자로 작성된 파일은 숫자 ID 65534가 소유한 것으로 표시되며, 이는 NFS 탑재에서 Linux 클라이언트의 "nfsnobody" 또는 "nobody" 사용자 이름에 해당합니다. 이는 일반적으로 NFSv4.x ID 도메인 문제로 나타나는 숫자 ID 99와 다릅니다. 사용 중인 숫자 ID를 확인하려면 ls -lan 명령을 사용합니다.
• 잘못된 소유자가 있는 파일은 UNIX 모드 비트 또는 NFSv4.x ACL에서 예상되는 결과를 제공하지 않습니다.
• NFSv4.x ACL은 NFS 클라이언트에서 관리됩니다. SMB 클라이언트는 NFSv4.x ACL을 보거나 관리할 수 없습니다.

NFSv4.x ACL을 사용하는 경우 umask의 영향

NFSv4 ACL은 ACL 상속을 제공하는 기능을 제공합니다. ACL 상속은 NFSv4 ACL이 설정된 개체 아래에 만들어진 파일 또는 폴더가 ACL 상속 플래그의 구성에 따라 ACL을 상속할 수 있음을 의미합니다.

umask는 디렉터리에 파일 및 폴더가 만들어지는 사용 권한 수준을 제어하는 데 사용됩니다. 기본적으로 Azure NetApp Files를 사용하면 umask가 상속된 ACL을 재정의할 수 있습니다. 이는 RFC-7530에 따라 예상되는 동작입니다.

자세한 내용은 umask를 참조하세요.

NFSv4.x ACL을 사용한 chmod/chown 동작

Azure NetApp Files에서 변경 소유권(chown) 및 변경 모드 비트(chmod) 명령을 사용하여 NFSv3 및 NFSv4.x에 대한 파일 및 디렉터리 권한을 관리할 수 있습니다.

NFSv4.x ACL을 사용하는 경우 파일 및 폴더에 더 세분화된 제어를 적용하면 chmod 명령의 필요성이 줄어듭니다. NFSv4.x ACL은 소유권을 할당하지 않으므로 아직 chown을 사용할 여지가 있습니다.

Azure NetApp Files에서 NFSv4.x ACL이 적용된 파일 및 폴더에 대해 chmod를 실행하면 개체에서 모드 비트가 변경됩니다. 또한 시스템 ACE 집합은 해당 모드 비트를 반영하도록 수정됩니다. 시스템 ACE가 제거되면 모드 비트가 지워집니다. 예와 더 자세한 설명은 아래 시스템 ACE의 섹션에서 볼 수 있습니다.

Azure NetApp Files에서 chown을 실행하면 할당된 소유자를 수정할 수 있습니다. ACL을 사용하면 기본 소유자/그룹/모든 사람 개념으로는 수행할 수 없는 방식으로 사용 권한을 제어할 수 있으므로 NFSv4.x ACL을 사용할 때는 모드 비트를 사용할 때만큼 파일 소유권이 중요하지 않습니다. 내보내기 제어는 루트만 소유권을 변경할 수 있도록 구성되므로 Azure NetApp Files의 chown은 루트로만 실행할 수 있습니다(루트로 또는 sudo 사용). 이는 Azure NetApp Files의 기본 정책 내보내기 규칙에 의해 제어되므로 소유권 수정을 허용하는 NFSv4.x ACL 항목은 적용되지 않습니다.

# 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 모드를 "무제한"으로 수정합니다.

수정한 후에는 적절한 액세스 권한이 있는 경우 루트 이외의 사용자가 소유권을 변경할 수 있습니다. 그렇게 하려면 "소유권 가져오기" 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

시스템 ACE

모든 ACL에는 일련의 시스템 ACE(OWNER@, GROUP@, EVERYONE@)가 있습니다. 예시:

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

이러한 ACE는 NFSv3에서 볼 수 있는 클래식 모드 비트 사용 권한에 해당하며 그러한 사용 권한과 직접 연결됩니다. 개체에서 chmod를 실행하면 이러한 시스템 ACL이 해당 사용 권한을 반영하도록 변경됩니다.

# 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

이러한 시스템 ACE가 제거되면 사용 권한 보기가 변경되어 일반 모드 비트(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

ACL(및 루트)의 사용자 및 그룹 보안 주체만 개체에 액세스할 수 있으므로 시스템 ACE를 제거하면 파일 및 폴더를 더욱 안전하게 보호할 수 있습니다. 시스템 ACE를 제거하면 기능에 대한 모드 비트 보기를 사용하는 애플리케이션이 중단될 수 있습니다.

NFSv4.x ACL을 사용하는 루트 사용자 동작

루트가 Squash되지 않는 한 NFSv4.x ACL을 사용하는 루트 액세스를 제한할 수 없습니다. 루트 Squash는 루트가 익명 사용자에 매핑되어 액세스를 제한하는 정책 내보내기 규칙을 구성하는 것입니다. 루트 액세스의 정책 규칙을 끄기로 변경하여 볼륨의 정책 내보내기 메뉴에서 루트 액세스를 구성할 수 있습니다.

루트 Squash를 구성하려면 볼륨의 정책 내보내기 메뉴로 이동한 다음, 정책 규칙에 대해 "루트 액세스"를 "끄기"로 변경합니다.

익명 사용자 nfsnobody:65534에 대한 루트 액세스 루트 Squash를 사용하지 않도록 설정하는 효과입니다. 그러면 루트 액세스에서 소유권을 변경할 수 없습니다.

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

또는 이중 프로토콜 환경에서 NTFS ACL을 사용하여 루트 액세스를 세분화하여 제한할 수 있습니다.

다음 단계

• NFS 클라이언트 구성
• NFSv4.1 볼륨에 대한 액세스 제어 목록 구성