파일 시스템 권한
"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차
1. 개요
파일 시스템 권한은 운영 체제에서 파일 및 디렉토리에 대한 접근을 제어하는 기능이다. 유닉스 계열 시스템은 전통적인 유닉스 권한 시스템을 사용하며, POSIX 표준에 정의된 소유자, 그룹, 기타 사용자에 대한 읽기, 쓰기, 실행 권한을 기반으로 한다. 이러한 권한은 기호 표기법과 숫자 표기법으로 표현되며, setuid, setgid, 스티키 비트와 같은 추가 권한을 가질 수 있다. 마이크로소프트 윈도우는 접근 제어 목록(ACL)을 사용하여 더 복잡한 권한 설정을 지원하며, 기타 운영 체제들도 각자의 권한 관리 방식을 가지고 있다. 일부 시스템은 사용자 개인 그룹(UPG)을 사용하여 파일 공유를 관리하기도 한다.
더 읽어볼만한 페이지
| 파일 시스템 권한 | |
|---|---|
| 파일 시스템 권한 | |
| 설명 | 파일 시스템에서 파일이나 디렉터리에 대한 접근 권한 |
| 종류 | |
| 기본 권한 | 읽기 (read) 쓰기 (write) 실행 (execute) |
| 추가 권한 | 소유자 (owner) 그룹 (group) 기타 사용자 (others) |
| 접근 제어 방법 | |
| 접근 제어 목록 (ACL) | 각 파일 및 디렉토리에 대한 접근 권한을 명시적으로 지정 |
| 역할 기반 접근 제어 (RBAC) | 사용자에게 역할을 할당하고 역할에 따라 권한을 부여 |
| 일반적인 운영 체제 | |
| 유닉스 계열 | chmod, chown 등의 명령어를 사용 |
| 윈도우 NT 계열 | NTFS 파일 시스템에서 ACL을 사용 |
2. 운영 체제에 따른 특징
리눅스 기반 시스템, OS X 모든 버전을 포함한 유닉스 계열 및 POSIX 호환 운영체제들은 파일 권한 관리를 위한 시스템을 갖추고 있다. 이 외에도 MS-DOS 계열, 윈도우 계열, 오픈VMS, 클래식 맥 OS, 아미가OS, 솔라리스, FreeBSD, IBM z/OS, OpenHarmony 등 다양한 운영체제들이 각기 다른 파일 시스템 권한 체계를 가지고 있다.
| 운영 체제 | 파일 시스템 | 권한 및 ACL 지원 | 비고 |
|---|---|---|---|
| 유닉스 계열 (리눅스, OS X 등) | "전통적인 유닉스 권한", 다양한 ACL 지원 (사유 방식, POSIX.1e, NFSv4) | ||
| MS-DOS 계열 (MS-DOS, 윈도우 95, 윈도우 98, 윈도우 미) | 권한 없음, 읽기 전용 파일 특성만 존재 | 사용자, 프로그램 제약없이 파일 변경 및 삭제 가능 | |
| DR DOS 계열 | FAT | 읽기/쓰기/실행/삭제 권한, 암호 설정 | DR DOS 6.0 이상은 다중 사용자 보안 모듈 필요 |
| 윈도우 NT 계열 (윈도우 2000, 윈도우 XP 포함) | NTFS | 접근 제어 목록(ACL) | |
| 오픈VMS | 유닉스와 유사, 4가지 범주(시스템, 소유자, 그룹, 월드), 4가지 접근 권한(읽기, 쓰기, 실행, 삭제) | 범주 간 포함 관계 존재 | |
| 클래식 맥 OS | HFS, HFS+ | 권한 없음, "보호된" 파일 특성만 지원 | |
| 아미가OS | 아미가도스 | ARWED(보관/읽기/쓰기/실행/삭제) 권한, 추가 플래그(Hold, Script, Pure) | |
| 솔라리스 | UFS | POSIX.1e ACL | |
| 솔라리스 | ZFS | NFSv4 ACL | [3] |
| FreeBSD | UFS | POSIX.1e ACL, NFSv4 ACL | [5] |
| FreeBSD | ZFS | NFSv4 ACL, 윈도 ACL | [6] |
| IBM z/OS | RACF | [7] | |
| OpenHarmony | 자체 Harmony 분산 파일 시스템 | 접근 토큰 관리자, 기능 기반 권한 관리 | [8] |
2. 1. 유닉스 계열 및 POSIX 호환 시스템
리눅스 기반 시스템 및 OS X 모든 버전을 포함한 유닉스 계열 및 기타 POSIX 호환 운영 체제들은 개개의 파일 권한을 관리하기 위한 단순한 시스템을 갖추고 있으며, 이를 "전통적인 유닉스 권한"이라고 부른다. 이들 시스템 대부분은 특정한 종류의 접근 제어 목록(ACL)을 지원한다. 지원되는 ACL은 다음과 같다:- 사유 방식 (구 HP-UX ACL 등)
- POSIX.1e ACL (현재는 버려진 초기 POSIX 초안 기반)
- NFSv4 표준의 일부인 NFSv4 ACL
솔라리스, 리눅스, FreeBSD, macOS의 ACL 지원 현황은 다음과 같다.
| 운영 체제 | 파일 시스템 | ACL 종류 | 비고 |
|---|---|---|---|
| 솔라리스 | UFS | POSIX.1e ACL | |
| 솔라리스 | ZFS | NFSv4 ACL | [22] |
| 리눅스 | ext2, ext3, ext4, Btrfs 등 | POSIX.1e ACL | |
| 리눅스 | ext3[23], ext4 | NFSv4 ACL | 실험적 지원 |
| FreeBSD | UFS | POSIX.1e ACL | |
| FreeBSD | UFS, ZFS | NFSv4 ACL | [24][25] |
| macOS | HFS+, APFS | POSIX 호환 권한 | |
| macOS | HFS+, APFS | NFSv4 ACL | 10.4 ("Tiger") 버전부터 지원 |
macOS는 POSIX 호환 권한과 NFSv4 ACL을 모두 지원하지만, 애플은 ''Mac OS X 서버 버전 10.4+ 파일 서비스 관리 설명서''에서 가능한 한 전통적인 유닉스 권한만 사용할 것을 권장한다.
유닉스 계열 시스템의 권한은 사용자(user), 그룹(group), 기타(others) 세 개의 클래스로 나누어 관리된다. 이는 접근 제어 목록을 단순화한 형태라고 볼 수 있다.
2. 2. 마이크로소프트 윈도우 계열
MS-DOS, 윈도우 95, 윈도우 98, 윈도우 미와 같은 운영 체제들은 파일 권한 없이 오직 파일 특성만을 가진다. 이 중 읽기 전용 특성(R)은 사용자나 프로그램이 설정하거나 해제할 수 있지만, 사용자가 파일을 변경하거나 삭제하는 것을 막지는 못한다. 사용자가 파일을 읽지 못하도록 하는 권한은 이러한 운영 체제에는 존재하지 않는다.[20]윈도우 NT 계열(윈도우 2000, 윈도우 XP 포함)은 접근 제어 목록(ACL)[20]을 사용하여 더 복잡하고 다양한 권한 설정을 관리한다. NTFS는 윈도우 NT 및 파생 제품에서 구현되었으며, 복잡한 권한 설정을 위해 ACL[1]을 사용한다.
2. 3. 기타 운영 체제
DR DOS 3.31 이상, 팜도스, 노벨 도스, 오픈도스, 플렉스OS, 4680 OS, 4690 OS, 컨커런트 도스, 멀티유저 도스, 데이터팩 시스템 매니저, IMS 리얼/32는 FAT 볼륨 상에서 파일 및 디렉터리에 대한 읽기/쓰기/실행/삭제 권한을 지원한다.[8] 플렉스OS, 4680 OS, 4690 OS를 제외한 이들 운영 체제들은 개개의 파일 및 디렉터리 암호 설정도 지원한다. DR DOS, 팜도스, 노벨 도스, 오픈도스를 제외한 이들 운영 체제들은 3개의 독립적인 파일/디렉터리 소유권 클래스(월드/그룹/소유자)를 지원하는 반면, DR DOS 6.0 이상, 팜도스, 노벨 도스, 오픈도스와 같은 단일 사용자 운영 체제들은 선택적 다중 사용자 보안 모듈을 사용할 경우에만 이 기능을 지원한다.오픈VMS는 유닉스와 유사한 권한 체계를 사용하지만 더 복잡하다. 시스템, 소유자, 그룹, 월드의 네 가지 범주와 읽기, 쓰기, 실행, 삭제의 네 가지 유형의 접근 권한이 있다.[2] 범주는 서로 배타적이지 않아 월드는 그룹을, 그룹은 소유자를 포함한다. 시스템 범주는 시스템 사용자를 독립적으로 포함한다.
클래식 맥 운영 체제들은 도스 변종들 및 도스 기반 윈도와 비슷하게 권한을 지원하지 않고 "보호된" 파일 특성만을 지원한다.
AmigaOS 파일 시스템, AmigaDOS는 단일 사용자 운영 체제를 위한 상대적으로 진보한 권한 시스템을 지원한다. AmigaOS 1.x에서 파일은 보관(A), 읽기(R), 쓰기(W), 실행(E), 삭제(D) 권한/플래그(ARWED)가 있다. AmigaOS 2.x 이상에서는 홀드(Hold), 스크립트(Script), 퓨어(Pure) 권한/플래그가 더 추가되었다.[8]
솔라리스의 ACL 지원은 사용되는 파일 시스템에 따라 다르다. 구 UFS 파일 시스템은 POSIX.1e ACL을 지원하지만, ZFS는 NFSv4 ACL만을 지원한다.[3]
FreeBSD는 UFS 상에서 POSIX.1e ACL을 지원하고 UFS와 ZFS 상에서 NFSv4나 윈도 ACL을 지원한다.[5][6]
IBM z/OS는 RACF (자원 접근 제어 관리 기능)를 통해 파일 보안을 구현한다.[7]
OpenHarmony 운영 체제는 접근 토큰 관리자(역할 기반 접근 제어)와 Core File Kit API의 기능 기반 세분화된 권한 관리를 지원한다.[8]
3. POSIX 권한
유닉스 계열 운영체제 파일 시스템의 권한은 POSIX.1-2017 표준[9]에 정의되어 있으며, '소유자', '그룹', '기타'의 세 가지 범주를 사용한다. 파일 생성 시 권한은 파일을 생성한 프로세스의 umask에 의해 제한된다.
3. 1. 클래스
유닉스 계열 운영체제 파일 시스템의 권한은 POSIX.1-2017 표준[9]에 정의되어 있으며, '소유자', '그룹', '기타'의 세 가지 범위 또는 클래스를 사용한다.- 사용자 클래스: 파일과 디렉터리는 특정 사용자가 소유하며, 소유자는 파일의 ''사용자 클래스''를 결정한다. 소유자에게는 별도의 권한이 적용된다.
- 그룹 클래스: 파일과 디렉터리에는 그룹이 할당되며, 이는 파일의 ''그룹 클래스''를 정의한다. 파일 그룹의 구성원에게는 별도의 권한이 적용된다. 소유자는 파일 그룹의 구성원일 수 있다.
- 기타 클래스: 소유자도 아니고 그룹의 구성원도 아닌 사용자는 파일의 ''기타 클래스''를 구성한다. 기타 사용자에게는 별도의 권한이 적용된다.
''유효 권한''은 사용자가 사용자, 그룹, 기타 순서로 속하는 첫 번째 클래스를 기반으로 결정된다. 예를 들어, 파일의 소유자인 사용자는 그룹 클래스 또는 기타 클래스에 할당된 권한에 관계없이 사용자 클래스에 부여된 권한을 갖게 된다.[9]
유닉스 계열 시스템의 권한은 "사용자(user)", "그룹(group)", "기타(others)"의 세 가지 "클래스"로 나누어 관리되며, 이는 접근 제어 목록을 단순화한 것이다.
3. 2. 기본 권한
유닉스 계열 운영체제 파일 시스템의 권한은 POSIX.1-2017 표준[9]에 정의되어 있으며, 파일을 생성한 프로세스의 umask에 의해 제한된다. 유닉스 계열 시스템은 '읽기', '쓰기', '실행'의 세 가지 권한을 구현한다.- '''읽기''' 권한은 파일을 읽을 수 있게 한다. 디렉터리에 설정된 경우, 디렉터리 내 파일의 '''이름'''을 읽을 수 있지만, 내용, 파일 형식, 크기, 소유권, 권한과 같은 추가 정보는 알 수 없다.
- '''쓰기''' 권한은 파일을 수정할 수 있게 한다. 디렉터리에 설정된 경우, 파일을 생성, 삭제, 이름 바꾸기를 할 수 있다. 이 권한은 ''실행'' 권한도 함께 설정되어야 의미가 있다.
- '''실행''' 권한은 파일을 실행할 수 있게 한다. 실행 가능한 프로그램에 설정되어야 하며, 디렉터리에 설정된 경우 ''검색'' 권한으로 해석된다. 즉, 파일 이름을 알고 있으면 파일 내용 및 메타 정보에 접근할 수 있지만, ''읽기'' 권한 없이는 디렉터리 내부 파일을 나열할 수 없다.
파일이 아닌 디렉터리에 권한을 설정하는 것은 "가장 자주 오해되는 파일 권한 문제 중 하나"이다.[10]
권한이 설정되지 않으면 거부된다. ACL 기반 시스템과 달리 유닉스 계열 시스템의 권한은 상속되지 않는다. 즉, 디렉토리 내에 생성된 파일이 해당 디렉터리와 동일한 권한을 가질 필요는 없다.
3. 3. 추가 권한 (setuid, setgid, sticky bit)
유닉스 계열 시스템은 세 가지 추가적인 권한 모드를 사용한다. 이들은 파일 또는 디렉터리 전체에 적용되며, 각각 setuid, setgid, 그리고 스티키 비트라고 불린다.- Set user ID (setuid): setuid가 설정된 파일을 실행하면, 실행되는 프로세스는 해당 파일의 소유자 권한을 갖게 된다. 예를 들어, 일반 사용자가 setuid가 설정된 root 소유의 파일을 실행하면, 그 프로세스는 일시적으로 root 권한을 얻게 된다.[1] 이를 통해 사용자는 임시적으로 root(또는 다른 사용자)로 취급될 수 있다.
- Set group ID (setgid): setgid가 설정된 파일을 실행하면, 실행되는 프로세스는 해당 파일의 그룹 권한을 갖게 된다. 디렉터리에 setgid가 설정되면, 그 하위에 생성되는 새로운 파일이나 디렉터리는 상위 디렉터리의 그룹 소유권을 상속받는다.[1]
- 스티키 비트: 디렉터리에 스티키 비트가 설정되면, 해당 디렉터리 내의 파일은 소유자만이 삭제하거나 이름을 변경할 수 있다. 디렉터리의 소유자와 슈퍼유저만이 이 예외를 받는다. 실행 파일에 대한 스티키 비트의 고전적인 동작은 커널이 종료 후에도 메모리에 결과 프로세스 이미지를 유지하도록 장려하는 것이었으나, 현대의 OS에서는 반드시 이미지를 유지하고 있다고는 할 수 없다.[1]
이러한 추가 권한들은 각각 하나의 비트만 차지하기 때문에 'setuid 비트', 'setgid 비트', '스티키 비트'라고도 불린다.[1]
4. 전통적인 유닉스 권한 표기법
유닉스 시스템에서 파일 및 디렉터리의 권한은 전통적인 방식으로 표현되고 관리된다. 이 방식은 사용자(user), 그룹(group), 기타 사용자(other)에게 각각 읽기(read), 쓰기(write), 실행(execute) 권한을 부여하거나 제한하는 것을 기본으로 한다.
파일 시스템 권한을 나타내는 방법으로는 기호 표기법과 숫자 표기법이 있다. 더 자세한 내용은 하위 섹션에서 확인할 수 있다.
4. 1. 기호 표기법 (Symbolic Notation)
`s` 또는 `t`: setuid/setgid 또는 스티키 (실행 가능)`S` 또는 `T`: setuid/setgid 또는 스티키 (실행 불가능)