Azure NetApp Files의 모드 비트 이해

NFS의 파일 액세스 권한에 따라 NAS 볼륨이 탑재되면 사용자 및 그룹이 수행할 수 있는 작업이 제한됩니다. 모드 비트는 Azure NetApp Files에서 NFS 파일 사용 권한의 주요 기능입니다.

NFS 모드 비트

NFS의 모드 비트 권한은 액세스 제어의 표준 숫자 표현을 사용하여 파일 및 폴더에 대한 기본 권한을 제공합니다. 모드 비트는 NFSv3 또는 NFSv4.1과 함께 사용할 수 있지만, 모드 비트는 RFC-1813에 정의된 대로 NFSv3을 보호하기 위한 표준 옵션입니다. 다음 표에서는 이러한 숫자 값이 액세스 제어에 어떻게 해당하는지 보여 줍니다.

모드 비트 숫자
1 – 실행(x)
2 – 쓰기(w)
3 – 쓰기/실행(wx)
4 – 읽기(r)
5 – 읽기/실행(rx)
6 – 읽기/쓰기(rw)
7 – 읽기/쓰기/실행(rwx)

숫자 값은 액세스 제어의 여러 세그먼트(소유자, 그룹 및 기타 모든 사람)에 적용됩니다. 즉, 기본 NFSv3에 대한 세분화된 사용자 액세스 제어가 없습니다. 다음 이미지는 NFSv3 개체와 함께 사용하기 위해 모드 비트 액세스 제어를 생성할 수 있는 방법의 예를 보여 줍니다.

.

Azure NetApp Files는 POSIX ACL을 지원하지 않습니다. 따라서 Active Directory LDAP와 같은 이름 서비스를 통해 유효한 UNIX와 Windows 이름 매핑이 있는 NTFS 보안 스타일 볼륨을 사용하는 경우에만 NFSv3를 사용하여 ACL을 세분화할 수 있습니다. 또는 NFSv4.1을 Azure NetApp Files 및 NFSv4.1 ACL과 함께 사용할 수 있습니다.

다음 표에서는 NFSv3 모드 비트와 NFSv4.x ACL 간의 사용 권한 세분성을 비교합니다.

NFSv3 모드 비트 NFSv4.x ACLs
  • 실행 시 사용자 ID 설정(setuid)
  • 실행 시 그룹 ID 설정(setgid)
  • 교환된 텍스트 저장(고정 비트)
  • 소유자의 읽기 권한
  • 소유자의 쓰기 권한
  • 파일에 대한 소유자의 실행 권한 또는 소유자의 디렉터리 조회(검색) 권한
  • 그룹의 읽기 권한
  • 그룹의 쓰기 권한
  • 파일에 대한 그룹의 실행 권한 또는 그룹의 디렉터리 조회(검색) 권한
  • 기타 사용자의 읽기 권한
  • 기타 사용자의 쓰기 권한
  • 파일에 대한 기타 사용자의 실행 권한 또는 기타 사용자의 디렉터리 조회(검색) 권한
  • ACE 유형(허용/거부/감사)
  • 상속 플래그:
  • directory-inherit
  • file-inherit
  • no-propagate-inherit
  • inherit-only
  • 사용 권한:
  • read-data(파일)/list-directory(디렉터리)
  • write-data(파일)/create-file(디렉터리)
  • append-data(파일)/create-subdirectory(디렉터리)
  • execute(파일)/change-directory(디렉터리)
  • delete
  • delete-child
  • read-attributes
  • write-attributes
  • read-named-attributes
  • write-named-attributes
  • read-ACL
  • write-ACL
  • write-owner
  • 동기화

자세한 내용은 NFSv4.x ACL(액세스 제어 목록) 이해를 참조하세요.

고정 비트, setuid 및 setgid

NFS 탑재와 함께 모드 비트를 사용하는 경우 파일 및 폴더의 소유권은 파일 및 폴더를 만든 사용자의 uidgid를 기반으로 합니다. 또한 프로세스가 실행되면 프로세스를 시작한 사용자로 실행되므로 그에 해당하는 사용 권한을 갖게 됩니다. 특수 권한(예: setuid, setgid, 고정 비트)을 사용하면 이 동작을 제어할 수 있습니다.

Setuid

setuid 비트는 사용 권한의 소유자 비트의 실행 부분에서 "s"로 지정합니다. setuid 비트는 사용자가 파일을 실행하려고 시도하는 대신, 파일의 소유자로 실행 파일을 실행할 수 있습니다. 예를 들어 /bin/passwd 애플리케이션에서는 기본적으로 setuid 비트가 활성화되므로 사용자가 암호를 변경하려고 할 때 애플리케이션이 루트로 실행됩니다.

# ls -la /bin/passwd 
-rwsr-xr-x 1 root root 68208 Nov 29  2022 /bin/passwd

setuid 비트가 제거되면 암호 변경 기능이 제대로 작동하지 않습니다.

# ls -la /bin/passwd
-rwxr-xr-x 1 root root 68208 Nov 29  2022 /bin/passwd
user2@parisi-ubuntu:/mnt$ passwd
Changing password for user2.
Current password: 
New password: 
Retype new password: 
passwd: Authentication token manipulation error
passwd: password unchanged

setuid 비트가 복원되면 passwd 애플리케이션이 소유자(루트)로 실행되고 제대로 작동하지만 passwd 명령을 실행하는 사용자에 대해서만 작동합니다.

# chmod u+s /bin/passwd
# ls -la /bin/passwd
-rwsr-xr-x 1 root root 68208 Nov 29  2022 /bin/passwd
# su user2
user2@parisi-ubuntu:/mnt$ passwd user1
passwd: You may not view or modify password information for user1.
user2@parisi-ubuntu:/mnt$ passwd
Changing password for user2.
Current password: 
New password: 
Retype new password: 
passwd: password updated successfully

Setuid는 디렉터리에 영향을 주지 않습니다.

Setgid

setgid 비트는 파일과 디렉터리 모두에서 사용할 수 있습니다.

디렉터리를 사용하는 경우 이 비트가 설정된 부모 디렉터리 아래에 만든 파일 및 폴더에 대한 소유자 그룹을 상속하는 방법으로 setgid를 사용할 수 있습니다. 실행 비트는 setuid처럼 "s" 또는 "S"로 변경됩니다.

참고 항목

대문자 "S"는 디렉터리에 대한 사용 권한이 "6" 또는 "rw"인 경우와 같이 실행 비트가 설정되지 않았음을 의미합니다.

예시:

# chmod g+s testdir
# ls -la | grep testdir
drwxrwSrw-  2 user1 group1     4096 Oct 11 16:34 testdir
# who
root     ttyS0        2023-10-11 16:28
# touch testdir/file
# ls -la testdir
total 8
drwxrwSrw- 2 user1 group1 4096 Oct 11 17:09 .
drwxrwxrwx 5 root  root   4096 Oct 11 16:37 ..
-rw-r--r-- 1 root  group1    0 Oct 11 17:09 file

파일의 경우 setgid는 그룹 소유자의 그룹 사용 권한을 사용하여 실행 파일을 실행하는 setuid와 유사하게 동작합니다. 사용자가 소유자 그룹에 속하는 경우 setgid를 설정하면 사용자가 실행 파일을 실행할 수 있는 권한을 갖습니다. 이 그룹에 속하지 않는 경우에는 액세스 권한이 없습니다. 예를 들어 관리자가 클라이언트에서 mkdir 명령을 실행할 수 있는 사용자를 제한하려는 경우 setgid를 사용할 수 있습니다.

일반적으로 /bin/mkdir에는 루트 소유권이 있는 사용 권한이 755개가 있습니다. 즉, 누구나 클라이언트에서 mkdir을 실행할 수 있습니다.

# ls -la /bin/mkdir 
-rwxr-xr-x 1 root root 88408 Sep  5  2019 /bin/mkdir

mkdir 명령을 실행할 수 있는 사용자를 제한하도록 동작을 수정하려면 mkdir 애플리케이션을 소유한 그룹을 변경하고 /bin/mkdir의 사용 권한을 750으로 변경한 다음 mkdir에 setgid 비트를 추가합니다.

# chgrp group1 /bin/mkdir
# chmod g+s /bin/mkdir
# chmod 750 /bin/mkdir
# ls -la /bin/mkdir
-rwxr-s--- 1 root group1 88408 Sep  5  2019 /bin/mkdir

결과적으로 이 애플리케이션은 group1의 사용 권한으로 실행됩니다. 사용자가 group1의 구성원이 아닌 경우 이 사용자는 mkdir을 실행할 수 있는 권한이 없습니다.

User1group1의 구성원이지만 user2는 아닙니다.

# id user1
uid=1001(user1) gid=1001(group1) groups=1001(group1)
# id user2
uid=1002(user2) gid=2002(group2) groups=2002(group2)

이 변경 후에 user1mkdir을 실행할 수 있지만 user2는 실행할 수 없습니다. user2group1에 속하지 않기 때문입니다.

# su user1
$ mkdir test
$ ls -la | grep test
drwxr-xr-x  2 user1 group1     4096 Oct 11 18:48 test

# su user2
$ mkdir user2-test
bash: /usr/bin/mkdir: Permission denied

고정 비트

고정 비트는 디렉터리에만 사용되며, 사용되는 경우 해당 모드 비트 사용 권한에 관계없이 해당 디렉터리에서 수정할 수 있는 파일을 제어합니다. 고정 비트가 설정되면 파일 사용 권한이 "777"로 표시되는 경우에도 파일 소유자(및 루트)만 파일을 수정할 수 있습니다.

다음 예에서 "sticky" 디렉터리가 Azure NetApp Fils 볼륨에 있으며 폭넓은 사용 권한을 포함하지만 고정 비트가 설정되어 있습니다.

# mkdir sticky
# chmod 777 sticky
# chmod o+t sticky
# ls -la | grep sticky
drwxrwxrwt  2 root  root       4096 Oct 11 19:24 sticky

폴더 안에는 다른 사용자가 소유한 파일이 있습니다. 모두 777개의 사용 권한이 있습니다.

# ls -la
total 8
drwxrwxrwt 2 root     root   4096 Oct 11 19:29 .
drwxrwxrwx 8 root     root   4096 Oct 11 19:24 ..
-rwxr-xr-x 1 user2    group1    0 Oct 11 19:29 4913
-rwxrwxrwx 1 UNIXuser group1   40 Oct 11 19:28 UNIX-file
-rwxrwxrwx 1 user1    group1   33 Oct 11 19:27 user1-file
-rwxrwxrwx 1 user2    group1   34 Oct 11 19:27 user2-file

일반적으로 누구나 이러한 파일을 수정하거나 삭제할 수 있습니다. 그러나 부모 폴더에 고정 비트가 설정되어 있으므로 파일 소유자만 파일을 변경할 수 있습니다.

예를 들어 user1은 user2-file을 수정하거나 삭제할 수 없습니다.

# su user1
$ vi user2-file
Only user2 can modify this file.
Hi
~
"user2-file"
"user2-file" E212: Can't open file for writing
$ rm user2-file 
rm: can't remove 'user2-file': Operation not permitted

반대로 user2user1-file을 소유하지 않으며 부모 디렉터리에 고정 비트가 설정되어 있으므로 이 파일을 수정하거나 삭제할 수 없습니다.

# su user2
$ vi user1-file
Only user1 can modify this file.
Hi
~
"user1-file"
"user1-file" E212: Can't open file for writing
$ rm user1-file 
rm: can't remove 'user1-file': Operation not permitted

그러나 루트는 여전히 파일을 제거할 수 있습니다.

# rm UNIX-file 

파일을 수정할 수 있는 루트의 권한을 변경하려면 Azure NetApp Files 정책 내보내기 규칙을 통해 루트를 다른 사용자에게 Squash해야 합니다. 자세한 내용은 루트 Squash를 참조하세요.

Umask

NFS 작업에서 사용 권한은 숫자 특성을 활용하여 파일 및 폴더 액세스를 결정하는 모드 비트를 통해 제어할 수 있습니다. 이러한 모드 비트는 읽기, 쓰기, 실행 및 특수 특성을 결정합니다. 사용 권한은 숫자로 다음과 같이 표시됩니다.

  • 실행 = 1
  • 읽기 = 2
  • 쓰기 = 4

총 사용 권한은 위의 조합을 더하거나 빼서 결정됩니다. 예시:

  • 4 + 2 + 1 = 7(모두 가능)
  • 4 + 2 = 6(읽기/쓰기)

자세한 내용은 UNIX 권한 도움말을 참조하세요.

umask는 관리자가 클라이언트에 허용되는 사용 권한 수준을 제한할 수 있는 기능입니다. 기본적으로 대부분의 클라이언트에 대한 umask는 0022로 설정됩니다. 0022는 해당 클라이언트에서 만든 파일에 해당 umask가 할당됨을 의미합니다. umask는 개체의 기본 사용 권한에서 뺍니다. 볼륨에 0777 사용 권한이 있고 이 볼륨이 NFS를 사용하여 umask가 0022인 클라이언트에 탑재된 경우, 이 클라이언트가 해당 볼륨에 작성한 개체에는 0755(0777 – 0022)개의 액세스 권한이 포함됩니다.

# umask
0022
# umask -S
u=rwx,g=rx,o=rx 

그러나 대부분의 운영 체제에서는 실행 권한으로 파일을 만들 수 없지만 폴더에 올바른 사용 권한을 포함할 수 있습니다. 따라서 umask 0022로 만든 파일은 사용 권한이 0644가 될 수 있습니다. 다음 예에서는 RHEL 6.5를 사용합니다.

# umask
0022
# cd /cdot
# mkdir umask_dir
# ls -la | grep umask_dir
drwxr-xr-x.  2 root     root         4096 Apr 23 14:39 umask_dir

# touch umask_file
# ls -la | grep umask_file
-rw-r--r--.  1 root     root            0 Apr 23 14:39 umask_file

다음 단계