파일 · 권한 · 사용자 관리 21 / 50 · Part 3. Linux 파일 권한
실습 환경: Rocky Linux 9.8 · Ubuntu 24.04.5 (Docker 격리 컨테이너, 테스트 계정analyst)
기초편 연계: 「리눅스 시스템 기초」 15. Linux 파일 권한 이해
1. 들어가며
Part 3 「Linux 파일 권한」을 시작한다. 파일 권한은 Linux 보안의 가장 기본 방어선이고, 침해사고의 상당수가 권한 설정 실수에서 출발한다.
이번 글에서는 권한의 뼈대를 정확히 세운다.
rwx와 소유자·그룹·기타 세 주체가 만드는 9비트 구조- 커널이 권한을 검사하는 순서 — 처음 일치하는 한 칸만 적용하고 합치지 않는다
- root의 예외
특히 "권한이 합쳐지지 않는다"는 규칙을 실습으로 확인한다. 소유자에게 권한이 없고 그룹에만 있는 파일은, 그룹 구성원은 접근할 수 있어도 소유자 본인은 접근할 수 없다.
「리눅스 시스템 기초 15편」이 권한을 한 번에 개괄했다면, Part 3는 기본 구조(21편) → 파일·디렉터리 차이(22편) → chmod(23·24편) → umask(25편) → 소유권(26·27편) → 특수 권한(28~30편)으로 세분화한다.
2. 핵심 개념
2-1. 세 주체와 세 권한
권한은 소유자(user) · 그룹(group) · 기타(other) 세 주체 각각에 대해 읽기(r) · 쓰기(w) · 실행(x) 을 정한다. 총 3 × 3 = 9비트다.
| 기호 | 값 | 파일에서 | 디렉터리에서 |
|---|---|---|---|
r | 4 | 내용 읽기 | 이름 목록 보기 |
w | 2 | 내용 수정 | 생성·삭제·이름 변경 |
x | 1 | 실행 | 진입·통과 |
- | 0 | 없음 | 없음 |
2-2. 8진수 표기
각 칸의 세 비트를 더하면 0~7의 숫자가 된다.
| 권한 | 계산 | 8진수 |
|---|---|---|
rwx | 4+2+1 | 7 |
r-x | 4+0+1 | 5 |
rw- | 4+2+0 | 6 |
r-- | 4+0+0 | 4 |
--- | 0 | 0 |
rwxr-x--- = 7·5·0 = 750.
2-3. 소유자와 그룹
모든 파일은 하나의 소유자(UID) 와 하나의 그룹(GID) 을 가진다. 프로세스가 파일에 접근하면 커널은 프로세스의 UID·GID를 파일의 소유자·그룹과 비교해 어느 칸을 적용할지 정한다.
3. 동작 원리
커널의 권한 검사는 위에서부터 처음 일치하는 한 칸에서 멈춘다.
- 프로세스가 root(UID 0) 면 읽기·쓰기 검사를 대부분 통과한다(
CAP_DAC_OVERRIDE). 단, 실행은x비트가 최소 하나는 있어야 한다. - 프로세스 UID = 파일 소유자 → user 칸만 적용하고 끝
- 프로세스의 그룹(보조 그룹 포함) = 파일 그룹 → group 칸만 적용하고 끝
- 나머지 → other 칸 적용
핵심은 권한이 합쳐지지 않는다 는 것이다. 소유자 칸에서 조건이 맞으면 그룹·기타 칸은 아예 보지 않는다. 그래서 ----rwx---(070) 파일은 그룹 구성원에게는 rwx이지만, 소유자 본인은 user 칸 ---에서 걸려 접근이 거부된다. 직관과 반대여서 자주 놓치는 지점이다.
4. 명령어 실습
report.sh는roror:dev소유의 754 파일이다.analyst는 소유자도 dev 그룹 구성원도 아니므로 other 칸(r--) 이 적용된다.owner-only.txt는analyst소유지만 권한이070이다.
cd /data/lab21
# 1) analyst 입장에서 report.sh (다른 사람 소유)
ls -l report.sh
stat -c '%A = %a (소유자 %U, 그룹 %G)' report.sh
id # analyst 는 dev 그룹이 아님
# 2) 소유자인데 권한이 070 인 파일
ls -l owner-only.txt
cat owner-only.txt # 소유자 본인도 Permission denied5. 실행 결과
텍스트 원본(실제 출력):
[analyst@rocky9-lab ~]$ cd /data/lab21
[analyst@rocky9-lab lab21]$ ls -l report.sh
-rwxr-xr-- 1 roror dev 7 Sep 24 10:50 report.sh
[analyst@rocky9-lab lab21]$ stat -c '%A = %a (소유자 %U, 그룹 %G)' report.sh
-rwxr-xr-- = 754 (소유자 roror, 그룹 dev)
[analyst@rocky9-lab lab21]$ id
uid=1000(analyst) gid=1000(analyst) groups=1000(analyst)
[analyst@rocky9-lab lab21]$ ls -l owner-only.txt
----rwx--- 1 analyst analyst 7 Sep 24 10:50 owner-only.txt
[analyst@rocky9-lab lab21]$ cat owner-only.txt
cat: owner-only.txt: Permission denied6. 결과 해석
| 출력 | 해석 |
|---|---|
-rwxr-xr-- roror dev | 소유자 roror는 rwx(7), dev 그룹은 r-x(5), 기타는 r--(4) → 754 |
id → uid=1000(analyst) ... groups=1000(analyst) | analyst는 roror도 아니고 dev 그룹도 아님 → other 칸(r--) 적용 |
analyst가 report.sh를 읽을 수 있음 | other의 r이 있으므로 읽기 가능. 실행(x)은 other에 없어 불가 |
----rwx--- analyst analyst owner-only.txt | 소유자 칸 ---(0), 그룹 칸 rwx(7), 기타 ---(0) → 070 |
cat owner-only.txt → Permission denied | 소유자 analyst 본인 이지만 user 칸이 ---. 커널은 user 칸에서 검사를 끝내고 그룹 칸(rwx)은 보지 않는다 |
owner-only.txt 결과가 이번 글의 핵심이다. "내 파일이니까 당연히 읽을 수 있다"는 가정은 틀렸다. 커널은 가장 먼저 일치하는 칸 만 본다.
7. 보안 관점
| 원리 | 보안적 의미 |
|---|---|
| 처음 일치하는 칸만 적용 | 권한을 넓게 주려고 그룹·기타에 권한을 추가해도, 소유자 칸이 좁으면 소유자는 여전히 막힌다. 반대로 소유자에게 필요한 권한만 정확히 줘야 한다 |
| 합쳐지지 않음 | "여러 그룹에 속하니 권한이 더해질 것"이라는 오해 방지. 파일 그룹과 일치하는 그룹의 칸만 적용된다 |
| root 예외 | root는 대부분의 권한 검사를 우회한다. 그래서 root 권한 탈취가 모든 파일 접근으로 이어진다. 최소 권한 원칙(45편)의 근거 |
| other 칸의 위험 | other에 w가 있으면 시스템의 누구나 파일을 바꿀 수 있다(world-writable, 46편) |
실무에서 자주 쓰는 안전한 기본값:
| 대상 | 권한 | 이유 |
|---|---|---|
| 개인 키·비밀 파일 | 600 | 소유자만 |
| 일반 설정 파일 | 644 | 소유자 쓰기, 나머지 읽기 |
| 실행 스크립트 | 755 | 모두 실행, 소유자만 수정 |
| 개인 디렉터리 | 700 | 소유자만 |
8. 보안관제 관점
| 관점 | 내용 |
|---|---|
| Detection | 권한 자체는 로그를 남기지 않는다. 변경은 chmod 시스템 콜(auditd)이나 FIM으로 탐지 |
| Investigation | 접근 거부(Permission denied)가 반복되면 공격자가 권한 없는 파일에 접근을 시도하는 정황일 수 있다. auditd -a always,exit -F arch=b64 -S open,openat -F success=0로 실패한 접근을 기록 가능 |
| 판단 | 넓은 권한(777, 666)은 취약 가능성이지 침해 자체는 아니다. 실제로 악용됐는지 는 로그로 확인 |
[점검] 비정상적으로 넓은 권한 탐색
find / -xdev -type f -perm -o+w ! -path '/proc/*' 2>/dev/null (46편)
↓
[판단] world-writable 파일이 root cron·서비스가 실행하는 파일인가?
↓
[Evidence] 해당 파일의 ctime(권한 변경 시각) + 내용 해시
↓
[Response] 권한 축소, 변경 주체 조사(sudo 로그, 49편)9. 실무에서 자주 발생하는 실수
| 실수 | 결과 | 예방 |
|---|---|---|
| 소유자에게 권한 없이 그룹에만 부여 | 소유자 본인 접근 불가 | user 칸부터 정확히 설정 |
| "여러 그룹 = 권한 합산"으로 오해 | 접근 예측 오류 | 파일 그룹과 일치하는 칸만 적용됨 |
문제 해결로 chmod 777 | 심각한 노출 | 필요한 주체·권한만 |
| root로 모든 걸 실행 | 권한 검사 무력화 | 서비스별 최소 권한 계정 |
other w 방치 | 누구나 수정 가능 | world-writable 정기 점검 |
10. 실습 체크리스트
[ ] rwx 를 8진수로 변환할 수 있다 (rwxr-x--- = 750)
[ ] 커널이 user → group → other 순으로 처음 일치하는 칸만 적용함을 이해했다
[ ] 다른 사람 소유 파일에서 other 칸이 적용되는 것을 확인했다
[ ] 070 파일을 소유자 본인이 읽지 못하는 것을 재현했다
[ ] root 가 권한 검사를 우회하는 이유를 설명할 수 있다
[ ] 600/644/755/700 의 용도를 말할 수 있다11. 핵심 정리
- 권한은 소유자·그룹·기타 × r(4)·w(2)·x(1) = 9비트이고 8진수로 표기한다.
- 커널은 소유자 → 그룹 → 기타 중 처음 일치하는 한 칸만 적용하고 합치지 않는다.
- 그래서 소유자 칸이 좁으면 그룹·기타에 권한이 있어도 소유자는 막힐 수 있다.
- root는 읽기·쓰기 검사를 우회한다(실행은
x하나 필요). - 넓은 권한은 취약 가능성이며, 실제 악용 여부는 로그로 판단한다.
- 안전한 기본값: 비밀 파일
600, 설정644, 스크립트755, 개인 디렉터리700.
12. 다음 편 예고
다음 글 「22. 파일과 디렉터리의 권한 차이」 에서는 같은 r·w·x가 파일과 디렉터리에서 전혀 다른 의미를 가진다는 것을 실습으로 확인한다. 특히 읽기 전용 파일이 삭제되는 이유 (파일 삭제 권한은 디렉터리의 w에서 나온다)를 재현한다.
참고 자료
- inode(7) — The file mode — https://man7.org/linux/man-pages/man7/inode.7.html
- path_resolution(7) — https://man7.org/linux/man-pages/man7/path_resolution.7.html
- credentials(7) — https://man7.org/linux/man-pages/man7/credentials.7.html
시리즈 이동
- [이전 글] 20. Linux 파일 무결성 확인 (sha256sum·rpm -V·debsums)
- [현재 글] 21. Linux 파일 권한의 기본 구조
- [다음 글] 22. 파일과 디렉터리의 권한 차이
