Linux 파일 권한과 특수 권한

1. ls -l의 권한 문자열은 파일 유형 1자리와 권한 9자리로 읽는다

다음은 학습용 예시다.

-rwxr-x---  1  alice  dev  4200  app

첫 10문자를 나누면 다음과 같다.

- | rwx | r-x | ---
↑    ↑      ↑      ↑
유형 owner  group  other

• 첫 문자 -: 일반 파일
• owner rwx: 소유자는 읽기·쓰기·실행 가능
• group r-x: 소유 그룹에 해당하는 사용자는 읽기·실행 가능
• other ---: 위 두 범주에 해당하지 않는 사용자는 허용된 기본 권한 없음

대표적인 첫 문자 의미는 다음과 같다.

파일 유형 문자는 권한 비트와 별개다. 예를 들어 d는 “디렉터리이므로 자동으로 접근 가능하다”는 뜻이 아니다. 뒤의 권한과 경로상의 디렉터리 탐색 권한이 별도로 필요하다.

2. owner·group·other는 세 권한을 모두 합산하는 방식이 아니다

기본 Unix/Linux 파일 권한 모델에서 중요한 순서는 다음과 같다.

1. 일반적인 경우 프로세스의 유효 사용자 ID가 파일 소유자와 일치하면 owner 비트를 사용한다.
2. 소유자와 일치하지 않고, 파일 그룹이 프로세스의 관련 그룹 ID와 일치하면 group 비트를 사용한다.
3. 둘 다 아니면 other 비트를 사용한다.

즉 “소유자이면서 그룹 멤버니까 owner와 group 권한을 합친다”라고 해석하지 않는다.

작은 예시

다음 파일을 가정한다. ACL이나 별도 특권은 없다고 한다.

----r-----  1  bob  dev  100  note.txt

권한은 다음과 같다.

owner = ---
group = r--
other = ---

bob이 dev 그룹에도 속해 있어도 이 파일의 소유자이므로 owner 클래스가 선택된다. owner가 ---이므로 기본 권한만 보면 읽을 수 없다.

bob은 dev 그룹이다
        ↓
그룹 r--도 더해서 읽는다        (X)

bob은 파일 소유자다
        ↓
owner ---가 적용된다            (O)

이 구분은 권한 문자열 해석 문제에서 매우 중요하다.

3. 일반 파일의 rwx와 디렉터리의 rwx는 같은 글자지만 동작 의미가 다르다

일반 파일

x 비트가 있다고 해서 어떤 바이트열도 반드시 실행에 성공하는 것은 아니다. 실행 형식, 인터프리터, 마운트 옵션 등 다른 조건도 영향을 줄 수 있다. 시험 기본 수준에서는 실행 권한 비트가 실행 허용의 핵심 조건 중 하나라고 이해한다.

디렉터리

디렉터리에서 가장 자주 틀리는 부분은 x다. 디렉터리의 x는 “디렉터리를 실행한다”는 뜻이 아니라 그 디렉터리를 경로 구성요소로 통과하고 이름을 탐색할 수 있는 권한이다.

r은 없고 x만 있는 디렉터리

알고 있는 파일 이름을 경로로 따라갈 수는 있지만, 디렉터리의 이름 목록 전체를 읽는 동작은 제한될 수 있다. 실제 파일 내용 접근에는 최종 파일 자체의 권한도 필요하다.

w는 있고 x가 없는 디렉터리

쓰기 비트 하나만으로는 일반적인 파일 생성·삭제 동작을 충분히 수행할 수 없다. 디렉터리 엔트리를 실제로 조작하려면 해당 디렉터리에 대한 탐색 권한도 함께 필요한 경우가 핵심이다.

삭제 권한은 대상 파일의 w만 보고 결정하지 않는다

파일 삭제는 파일 내용에 글자를 쓰는 작업이 아니라 부모 디렉터리에서 이름과 inode의 연결을 제거하는 디렉터리 엔트리 조작이다. 따라서 기본적으로 부모 디렉터리의 권한이 중요하다.

이 때문에 다음 상황이 가능하다.

파일 자체는 읽기 전용
부모 디렉터리에 필요한 w+x 보유
        ↓
그 파일의 디렉터리 엔트리 삭제가 가능할 수 있음

다만 Sticky bit가 설정된 공유 디렉터리라면 삭제·이름 변경 조건이 추가로 제한된다.

4. 숫자 권한은 r=4, w=2, x=1을 owner·group·other별로 합산한다

기본 권한 비트는 다음 값으로 표현할 수 있다.

따라서 다음처럼 계산한다.

rwx = 4 + 2 + 1 = 7
rw- = 4 + 2     = 6
r-x = 4 + 1     = 5
r-- = 4         = 4

예: chmod 640 report.txt

6 = rw-   owner
4 = r--   group
0 = ---   other

결과는 다음과 같이 해석한다.

-rw-r-----

기호 방식도 함께 알아야 한다

chmod는 8진수뿐 아니라 기호 방식으로 특정 범주의 권한만 변경할 수 있다.

chmod u+x deploy.sh
chmod g-w report.txt
chmod o= secret.txt
chmod u=rw,g=r,o= report.txt

기호는 다음처럼 읽는다.

• u: owner(user)
• g: group
• o: other
• a: all
• +: 권한 추가
• -: 권한 제거
• =: 지정한 권한으로 설정

재귀 변경인 chmod -R은 하위 파일과 디렉터리에 광범위한 영향을 주므로 실제 운영에서는 대상과 결과를 먼저 확인해야 한다.

5. 소유자와 소유 그룹은 chmod로 바꾸는 값이 아니다

chmod는 mode bit, 즉 접근 권한 비트를 바꾸는 명령이다. 소유자와 소유 그룹 변경은 다른 관리 동작이다.

대표적인 형태는 다음과 같다.

chown alice report.txt
chown alice:dev report.txt
chgrp dev report.txt

역할을 구분하면 다음과 같다.

Linux에서 파일 소유자를 다른 UID로 바꾸는 작업은 특권이 필요하다. 반면 파일 소유자는 조건을 만족하면 자신이 속한 그룹 중 하나로 파일 그룹을 변경할 수 있다. 따라서 “소유자나 그룹 변경은 언제나 root만 가능하다”라고 절대 규칙으로 외우면 부정확하다.

또한 소유자나 그룹 변경은 실행 파일의 SetUID/SetGID 같은 특수 비트에 영향을 줄 수 있으므로, 권한 상승 경로가 우연히 유지되지 않는지 함께 확인해야 한다.

6. umask는 새 객체를 만들 때 허용 후보 권한에서 특정 비트를 끄는 생성 마스크다

umask를 “기본 권한에서 무조건 숫자로 뺀다”고 외우면 일부 값에서 잘못 계산할 수 있다. 핵심은 비트 마스크다.

일반적인 계산 개념은 다음과 같다.

최종 생성 권한 = 요청된 생성 mode & ~umask

일반적인 셸 환경에서 설명할 때 자주 사용하는 후보 mode는 다음과 같다.

일반 파일: 0666  (rw-rw-rw-)
디렉터리: 0777  (rwxrwxrwx)

일반 파일에 기본적으로 실행 비트를 넣지 않는 이유는 “새 데이터 파일이 자동으로 실행 가능해지는 것”을 피하는 전형적인 생성 방식과 연결된다.

예 1: umask 022

일반 파일: 0666 & ~0022 = 0644 → rw-r--r--
디렉터리: 0777 & ~0022 = 0755 → rwxr-xr-x

예 2: umask 027

일반 파일: 0666 & ~0027 = 0640 → rw-r-----
디렉터리: 0777 & ~0027 = 0750 → rwxr-x---

왜 단순 뺄셈으로만 외우면 안 되는가

마스크는 “이 비트를 금지한다”는 개념이다. 따라서 논리 연산 관점으로 이해하면 비정상적인 조합에서도 원리를 유지할 수 있다.

또한 디렉터리에 Default ACL이 설정되어 있는 환경에서는 새 객체의 권한 결정에 해당 ACL이 개입한다. 이 경우 umask만으로 최종 결과를 단정해서는 안 된다.

umask

값을 바꾸면 현재 셸과 그 뒤에 생성되는 프로세스·파일 생성 동작에 영향을 줄 수 있으므로 실제 운영 환경에서는 정책을 확인하고 변경한다.

좌우로 이동해 그림을 확인하세요.그림 크게 보기

7. 특수 권한은 기본 rwx 9비트 앞에 추가되는 SetUID·SetGID·Sticky bit다

특수 권한의 8진수 자리는 다음과 같다.

예를 들어 4755는 다음처럼 분해한다.

4 | 7 | 5 | 5
↑   ↑   ↑   ↑
SUID owner group other

8. SetUID는 “항상 root 권한”이 아니라 실행 파일 소유자의 유효 UID와 연결된다

실행 가능한 일반 파일에 Set-user-ID(SetUID) 가 유효하게 설정되어 있으면, 그 파일을 실행한 프로세스의 Effective UID(EUID) 가 파일 소유자의 UID로 바뀌는 방식으로 동작할 수 있다.

핵심 관계는 다음과 같다.

실행 사용자 UID         = 1001
실행 파일 소유자 UID     = 0
실행 파일에 SetUID 설정
        ↓
실행 시 EUID가 파일 소유자 UID 0으로 설정

하지만 다음처럼 일반화하면 안 된다.

SetUID = 무조건 root 권한                  (X)
SetUID = 파일 소유자의 유효 UID로 실행됨     (O, 기본 개념)

파일 소유자가 UID 2000이면 SetUID의 핵심은 UID 2000과 연결되는 것이지 자동으로 UID 0이 되는 것이 아니다.

대표적인 표시 예시는 다음과 같다.

-rwsr-xr-x

owner의 실행 자리 x가 s로 보인다.

chmod u+s program
# 또는 권한 전체를 의도적으로 지정하는 예
chmod 4755 program

여기서는 SetUID가 유효한 일반 실행 파일을 가정한다. nosuid 마운트 등으로 이 동작이 제한될 수 있다.

SetUID 실행 파일은 권한 경계를 바꾸는 기능이므로 불필요하거나 취약한 실행 파일에 설정되어 있으면 위험하다. 운영 점검에서는 “SetUID가 존재한다”만으로 취약하다고 단정하기보다 파일 소유자, 실행 목적, 쓰기 가능 여부, 실제 필요성을 함께 확인한다.

9. SetGID는 실행 파일과 디렉터리에서 중요한 의미가 다르다

실행 파일의 SetGID

실행 가능한 일반 파일에 Set-group-ID(SetGID)가 유효하게 적용되면 실행 프로세스의 Effective GID(EGID) 가 파일의 소유 그룹과 연결될 수 있다.

-rwxr-sr-x

group의 실행 자리에서 s가 보인다.

디렉터리의 SetGID

공동 작업 디렉터리에서는 SetGID가 특히 중요하다. SetGID가 설정된 디렉터리 안에서 새로 만드는 파일·디렉터리는 부모 디렉터리의 그룹을 상속하는 방식으로 동작한다.

예를 들어 다음 구조를 생각해 보자.

/shared
소유 그룹 = project
권한      = drwxrwsr-x

/shared 안에서 여러 사용자가 새 파일을 만들 때 각 사용자의 기본 그룹으로 제각각 생성되는 대신, project 그룹을 이어받도록 구성할 수 있다. 협업 디렉터리에서 그룹 일관성을 유지하는 데 유용하다.

chmod g+s /shared
# 또는
chmod 2775 /shared

SetGID도 “그룹 권한이 모두 자동 허용된다”는 뜻은 아니다. 새 객체의 실제 rwx, umask, ACL 등은 별도로 작용한다.

10. Sticky bit는 공유 디렉터리에서 다른 사용자의 파일을 함부로 삭제·이름 변경하지 못하게 제한한다

여러 사용자가 쓸 수 있는 디렉터리에 w+x가 있으면 다른 사용자의 디렉터리 엔트리를 지울 수 있는 위험이 생긴다. Sticky bit는 이런 공유 디렉터리의 삭제·이름 변경을 제한하는 데 사용된다.

대표적인 형태는 다음과 같다.

drwxrwxrwt

other의 실행 위치가 t로 표시된다.

chmod +t /shared-temp
# 또는
chmod 1777 /shared-temp

Sticky bit가 설정된 디렉터리에서는 일반적으로 파일 삭제·이름 변경을 파일 소유자, 디렉터리 소유자 또는 필요한 특권을 가진 프로세스 등으로 제한한다.

중요한 점은 Sticky bit가 파일 내용 자체의 읽기·쓰기 권한을 대신하지 않는다는 것이다.

Sticky bit → 디렉터리 엔트리 삭제/이름 변경 제한
파일 rwx   → 파일 내용 읽기/쓰기/실행 판단

두 기능을 분리해야 한다.

11. s/S, t/T의 대소문자는 실행 비트가 함께 있는지 보여준다

ls -l에서 특수 권한이 보일 때 소문자와 대문자의 차이를 알아야 한다.

예를 들어 다음을 비교한다.

-rwsr-xr-x   → owner x + SetUID
-rwSr--r--   → SetUID는 있지만 owner x 없음

drwxrwxrwt   → other x + Sticky bit
drwxrw-rwT   → Sticky bit는 있지만 other x 없음

S나 T가 보인다고 해서 그 자체가 곧 공격 성공을 의미하는 것은 아니다. 권한 조합이 의도한 동작과 맞는지를 점검해야 한다.

12. 작은 권한 문제를 단계별로 해석하는 방법

상황 A: 일반 파일

-rw-r-----  1  alice  dev  ...  report.txt

사용자 kim은 dev 그룹 멤버이고 파일 소유자는 아니다.

1. owner 일치? → 아니오
2. group 일치? → 예
3. group 비트 r-- 적용
4. 읽기 → 허용
5. 쓰기 → 거부

상황 B: 디렉터리

drwx-wx---  2  alice  dev  ...  work

kim은 dev 그룹 멤버라고 하자.

• group w+x가 있으므로 이름을 알고 있고 상위 경로 조건도 만족하면 디렉터리 엔트리를 생성·삭제하는 동작이 가능할 수 있다.
• group r이 없으므로 디렉터리 이름 목록을 일반적으로 읽는 것은 허용되지 않는다.

즉 “목록을 못 보니까 아무 작업도 못 한다”와 “w가 있으니 x 없이도 무엇이든 만든다”는 둘 다 단순화다.