파일 · 권한 · 사용자 관리 30 / 50 · Part 3. Linux 파일 권한
실습 환경: Rocky Linux 9.8 · Ubuntu 24.04.5 (Docker 격리 컨테이너, 테스트 계정analyst)
기초편 연계: 「리눅스 시스템 기초」 16. chmod와 권한 관리
1. 들어가며
Part 3의 마지막 글이다. /tmp는 시스템의 모든 사용자가 파일을 만들 수 있는 공용 디렉터리다(권한 1777). 그런데 22편에서 배웠듯 파일 삭제 권한은 상위 디렉터리의 w에서 나온다. 그렇다면 누구나 쓸 수 있는 /tmp에서는 누구나 남의 파일을 삭제 할 수 있어야 한다. 실제로는 그렇지 않다.
그 이유가 권한 1777의 맨 앞 1 — Sticky Bit 다. Sticky Bit는 공용 디렉터리에서 파일 삭제·이름 변경을 소유자로 제한 한다. 이번 글에서는 Sticky Bit가 있을 때와 없을 때의 차이를 실습으로 재현한다.
2. 핵심 개념
2-1. Sticky Bit의 효과
Sticky Bit가 설정된 디렉터리에서는, 그 안의 파일을 삭제하거나 이름을 바꿀 수 있는 사람 이 다음으로 제한된다.
- 파일의 소유자
- 디렉터리의 소유자
- root
디렉터리에 w가 있어도, 위 세 경우가 아니면 남의 파일을 삭제할 수 없다.
2-2. 표기와 설정
| 표시 | 의미 |
|---|---|
drwxrwxrwt | Sticky Bit + other 실행 (소문자 t) |
drwxrwxrwT | Sticky Bit인데 other 실행 없음 (대문자 T) |
chmod 1777 | 앞자리 1 = Sticky |
chmod +t | 기호 방식 |
2-3. 특수 권한 세 개 정리
| 특수 권한 | 값 | 파일 | 디렉터리 |
|---|---|---|---|
| SUID | 4 | 소유자 권한 실행 | (효과 없음) |
| SGID | 2 | 그룹 권한 실행 | 그룹 상속 |
| Sticky | 1 | (거의 효과 없음) | 삭제를 소유자로 제한 |
세 특수 권한은 네 자리 8진수의 맨 앞자리에 들어간다. 1777, 2775, 4755처럼.
3. 동작 원리
22편에서 파일 삭제(unlink)는 파일이 아니라 디렉터리를 수정하는 작업 이라고 했다. 그래서 삭제 권한은 디렉터리의 w가 결정한다. /tmp는 1777이라 모든 사용자에게 w가 있으므로, Sticky Bit가 없다면 누구나 남의 임시 파일을 삭제·교체할 수 있다.
이것은 심각한 문제다. 공격자가 다른 사용자의 /tmp 파일을 자기 것으로 바꿔치기하면, 그 파일을 신뢰하는 프로그램을 속일 수 있다(심볼릭 링크 공격과 결합). Sticky Bit는 삭제·이름 변경만 소유자로 제한해 이 공격을 막는다. 파일 생성 은 여전히 누구나 할 수 있다.
/tmp, /var/tmp, /dev/shm이 모두 1777인 이유가 이것이다.
4. 명령어 실습
sticky(1777)와nosticky(0777) 두 디렉터리에 각각 analyst 소유 파일과 root 소유 파일을 미리 넣어 뒀다. analyst 입장에서 남의 파일(root 소유) 삭제 를 시도한다.
cd /data/lab30
# 1) 두 디렉터리 비교
ls -ld sticky nosticky # sticky 에만 t
ls -l sticky # analyst 파일 + root 파일
# 2) Sticky 디렉터리 — 남의 파일 삭제 시도
rm -f sticky/root-file # Operation not permitted
rm -f sticky/a-file # 내 파일은 삭제됨
# 3) Sticky 없는 0777 디렉터리 — 남의 파일도 삭제됨
rm -f nosticky/root-file # 삭제 성공 (위험!)
# 참고: /tmp 확인
ls -ld /tmp /var/tmp5. 실행 결과
텍스트 원본(실제 출력):
[analyst@rocky9-lab ~]$ cd /data/lab30
[analyst@rocky9-lab lab30]$ ls -ld sticky nosticky
drwxrwxrwx 2 root root 4096 Sep 24 10:57 nosticky
drwxrwxrwt 2 root root 4096 Sep 24 10:57 sticky
[analyst@rocky9-lab lab30]$ ls -l sticky
total 8
-rw-r--r-- 1 analyst analyst 13 Sep 24 10:57 a-file
-rw-r--r-- 1 root root 11 Sep 24 10:57 root-file
[analyst@rocky9-lab lab30]$ echo "== sticky 디렉터리: 남의 파일 삭제 시도 =="
== sticky 디렉터리: 남의 파일 삭제 시도 ==
[analyst@rocky9-lab lab30]$ rm -f sticky/root-file 2>&1 || echo "→ Sticky Bit: 소유자 아니면 삭제 불가"
rm: cannot remove 'sticky/root-file': Operation not permitted
→ Sticky Bit: 소유자 아니면 삭제 불가
[analyst@rocky9-lab lab30]$ rm -f sticky/a-file && echo "→ 내 파일은 삭제됨"
→ 내 파일은 삭제됨
[analyst@rocky9-lab lab30]$ echo "== nosticky(0777): 남의 파일 삭제 시도 =="
== nosticky(0777): 남의 파일 삭제 시도 ==
[analyst@rocky9-lab lab30]$ rm -f nosticky/root-file && echo "→ Sticky 없음: 남의 파일도 삭제됨!"
→ Sticky 없음: 남의 파일도 삭제됨!6. 결과 해석
| 출력 | 해석 |
|---|---|
drwxrwxrwt ... sticky | 맨 끝 t = Sticky Bit |
drwxrwxrwx ... nosticky | Sticky 없는 0777 |
rm sticky/root-file → Operation not permitted | Sticky Bit가 남의 파일 삭제를 차단 |
rm sticky/a-file → 성공 | 내 소유 파일은 삭제 가능 |
rm nosticky/root-file → 성공 | Sticky 없으면 남의 파일도 삭제됨 |
sticky와 nosticky의 차이가 명확하다. 같은 777 권한이라도 Sticky Bit 하나가 공용 디렉터리의 안전을 좌우한다.
7. 보안 관점
| 주제 | 내용 |
|---|---|
| 공용 디렉터리 필수 설정 | /tmp, /var/tmp, /dev/shm은 반드시 1777. Sticky 누락은 취약점 |
| 심볼릭 링크 공격과 결합 | Sticky가 없으면 공격자가 남의 임시 파일을 교체·링크로 바꿔치기 가능. Sticky + fs.protected_symlinks(14편)가 함께 방어 |
| 파일 생성은 여전히 가능 | Sticky는 삭제만 제한한다. 공용 디렉터리에 악성 파일을 두는 것 은 막지 못한다 |
| 애플리케이션 임시 파일 | 공유 디렉터리에 고정 이름 파일을 만들면 선점 공격 대상. mktemp 사용(07편) |
점검 항목: /tmp, /var/tmp, /dev/shm의 Sticky Bit 존재 여부는 CIS 벤치마크의 기본 점검 항목이다.
# Sticky Bit 없이 world-writable 인 디렉터리 (위험)
find / -xdev -type d -perm -0002 ! -perm -1000 2>/dev/null8. 보안관제 관점
[점검] Sticky 없는 world-writable 디렉터리
find / -xdev -type d -perm -0002 ! -perm -1000 2>/dev/null
stat -c '%A %a %n' /tmp /var/tmp /dev/shm # 1777 확인
↓
[판단] 공용 디렉터리에 Sticky 누락 → 파일 바꿔치기·삭제 위험
↓
[Evidence] 해당 디렉터리 권한 변경 시각(ctime), 안의 파일 목록
↓
[Response] chmod +t 로 복구, 변경 경위 조사| 관점 | 내용 |
|---|---|
| Baseline | 공용 디렉터리의 1777 권한을 기준값으로 관리 |
| 탐지 | /tmp 등의 권한 변경(Sticky 제거)을 FIM으로 감시 |
| 결합 방어 | Sticky + protected_symlinks/protected_hardlinks + mktemp 관행 |
9. 실무에서 자주 발생하는 실수
| 실수 | 결과 | 예방 |
|---|---|---|
/tmp 문제 해결로 chmod 777 | Sticky 제거 → 파일 바꿔치기 위험 | chmod 1777 |
| 공유 디렉터리에 Sticky 미설정 | 남의 파일 삭제 가능 | 공용 디렉터리는 1777 |
| Sticky로 파일 생성도 막힌다고 오해 | 생성은 여전히 가능 | Sticky는 삭제·이름 변경만 제한 |
| 임시 파일에 고정 이름 | 선점 공격 | mktemp |
| SUID/SGID/Sticky 자리 혼동 | 잘못된 특수 권한 | 앞자리 4/2/1 구분 |
10. 실습 체크리스트
[ ] Sticky 디렉터리에서 남의 파일 삭제가 거부되는 것을 확인했다
[ ] 내 파일은 삭제되는 것을 확인했다
[ ] Sticky 없는 0777 에서 남의 파일이 삭제되는 것을 재현했다
[ ] /tmp 가 1777 인 것을 확인했다
[ ] drwxrwxrwt 의 t 를 찾을 수 있다
[ ] Sticky 없는 world-writable 디렉터리를 find 로 점검할 수 있다11. 핵심 정리
- Sticky Bit는 공용 디렉터리에서 파일 삭제·이름 변경을 소유자·디렉터리 소유자·root로 제한 한다.
- 파일 생성 은 여전히 누구나 가능하다.
- 표기는
drwxrwxrwt, 설정은chmod 1777또는+t. /tmp·/var/tmp·/dev/shm은 반드시1777이어야 한다.- Sticky 누락 + world-writable은 파일 바꿔치기 취약점이다.
- 특수 권한 앞자리: SUID=4, SGID=2, Sticky=1.
Part 3 정리 — 21~30편에서 권한 9비트, 파일·디렉터리 차이, chmod(기호·숫자), umask, 소유권(chown·chgrp), 특수 권한(SUID·SGID·Sticky)까지 권한 체계 전체 를 다뤘다. Part 4부터는 이 권한의 주체인 사용자와 그룹 을 파고든다.
12. 다음 편 예고
Part 4 「사용자와 그룹 관리」를 시작한다. 다음 글 「31. Linux 사용자 계정 구조」 에서는 UID·사용자명·홈 디렉터리·로그인 셸로 이루어진 계정의 구조와, UID 0(root)·시스템 계정·일반 계정의 구분을 다룬다.
참고 자료
- inode(7) — The sticky bit — https://man7.org/linux/man-pages/man7/inode.7.html
- Filesystem Hierarchy Standard — /tmp — https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s18.html
- CIS Benchmarks — https://www.cisecurity.org/cis-benchmarks
시리즈 이동
- [이전 글] 29. SGID 권한
- [현재 글] 30. Sticky Bit
- [다음 글] 31. Linux 사용자 계정 구조
