파일 권한 (File Permissions)

Linux 파일 권한은 9비트로 표현됩니다. `ls -la` 출력의 첫 번째 필드를 읽는 법을 익히는 것이 출발점입니다.

확대

각 기호가 파일과 디렉토리에서 의미하는 바가 다릅니다. 특히 x 권한은 파일이면 실행, 디렉토리이면 진입(cd) 허용을 뜻한다는 점을 기억하세요.

숫자 표기법: 각 주체의 권한을 더해서 표현합니다.

• rwx = 4+2+1 = 7
• r-x = 4+0+1 = 5
• r-- = 4+0+0 = 4
• 755 = owner(rwx=7) + group(r-x=5) + others(r-x=5)
• 644 = owner(rw-=6) + group(r--=4) + others(r--=4)
• 600 = owner(rw-=6) + group(---=0) + others(---=0)

실무에서 가장 자주 쓰는 조합:

• 755 — 실행 가능한 스크립트, 디렉토리
• 644 — 설정 파일, 웹 콘텐츠
• 600 — SSH 키, 비밀번호 파일
• 640 — 그룹 구성원만 읽어야 하는 로그
• 777 — 절대 프로덕션에서 쓰면 안 됨

일반 rwx 9비트 외에 3개의 특수 비트가 있습니다. 보안 감사와 공유 디렉토리 설계에서 반드시 알아야 합니다.

SUID (Set User ID) — 비트값 4000

SUID가 설정된 실행 파일은, 실행하는 사람의 권한이 아닌 파일 소유자의 권한으로 실행됩니다.

# 실습 디렉토리 준비
mkdir -p /tmp/linux/part1/exam_5 && cd /tmp/linux/part1/exam_5

# passwd 명령이 대표적인 SUID 예시
ls -la /usr/bin/passwd
# -rwsr-xr-x  1  root  root  ...  /usr/bin/passwd
#    ^
#    s = SUID 비트 (소문자 s = 실행 권한 있음, 대문자 S = 실행 권한 없음)

일반 사용자는 /etc/shadow를 읽거나 쓸 수 없지만, passwd 명령은 root 소유에 SUID가 설정되어 있어 실행 시 root 권한으로 /etc/shadow를 수정할 수 있습니다.

보안 함의: SUID가 설정된 파일이 취약하면 권한 상승(privilege escalation) 공격 경로가 됩니다. 정기적으로 목록을 감사해야 합니다.

# 시스템 전체에서 SUID 파일 찾기 (보안 감사)
find / -perm -4000 -type f 2>/dev/null

SGID (Set Group ID) — 비트값 2000

• 실행 파일에 설정: SUID와 동일하게 그룹 기준으로 동작
• 디렉토리에 설정: 해당 디렉토리 안에 생성되는 모든 파일이 디렉토리의 그룹을 상속

# 공유 디렉토리 설정 예시
ls -ld /opt/shared/
# drwxrwsr-x  2  root  devteam  4096  ...  /opt/shared/
#       ^
#       s = SGID 비트

Sticky Bit — 비트값 1000

디렉토리에 설정 시, 해당 디렉토리 안의 파일은 파일 소유자나 root만 삭제 가능합니다. 다른 사용자가 쓰기 권한이 있어도 남의 파일은 지울 수 없습니다.

# /tmp가 대표 예시
ls -ld /tmp
# drwxrwxrwt  ...  /tmp
#          ^
#          t = sticky bit (소문자 t = 실행 권한 있음)

/tmp는 모든 사용자가 파일을 만들 수 있지만(rwxrwxrwx), sticky bit 덕분에 자기 파일만 지울 수 있습니다.

특수 비트 숫자 표기법:

특수 비트는 일반 3자리 숫자 앞에 한 자리를 추가해서 표현합니다. 4000은 SUID, 2000은 SGID, 1000은 Sticky Bit입니다.

chmod 4755 /usr/local/bin/mytool   # SUID + 755
chmod 2775 /opt/shared             # SGID + 775
chmod 1777 /tmp                    # Sticky + 777

커널이 rwx를 판정하는 순서 — owner→group→other

[프로세스]  open("/opt/app/app.yml", O_RDONLY)   euid=1000(deploy)
   │
   ① 파일 소유 uid == 프로세스 euid ?
   │      예    → owner 3비트(rwx)로 판정하고 즉시 끝
   │      아니오 ↓
   ② 파일 소유 gid 가 내 그룹(주·보조)에 있나 ?
   │      예    → group 3비트(rwx)로 판정하고 즉시 끝
   │      아니오 ↓
   ③ 그 외     → others 3비트(rwx)로 판정
   │
   ④ 고른 3비트에 요청 동작(r·w·x)이 있으면 허용
   │      없으면 즉시 EACCES (Permission denied)
   ▼
[결과]  접근 허용   또는   Permission denied

ls -la /etc/passwd /etc/shadow /usr/bin/passwd

-rw-r--r--  1  root  root    2847  Mar 26  /etc/passwd
-rw-r-----  1  root  shadow  1423  Mar 26  /etc/shadow
-rwsr-xr-x  1  root  root   68208  Mar 26  /usr/bin/passwd

# 실습 디렉토리 준비
mkdir -p /tmp/linux/part2/exam_1 && cd /tmp/linux/part2/exam_1
touch deploy.sh
ls -la deploy.sh

-rw-r--r--  1  ubuntu  ubuntu  0  Mar 26  deploy.sh

# 심볼릭 모드로 권한 변경
chmod u+x deploy.sh          # 소유자에게 실행 권한 추가
chmod g-w deploy.sh          # 그룹에서 쓰기 권한 제거
chmod o=r deploy.sh          # others는 읽기만

# 또는 한 번에
chmod u+x,g=rx,o-rwx deploy.sh
ls -la deploy.sh

-rwxr-x---  1  ubuntu  ubuntu  0  Mar 26  deploy.sh

mkdir -p /tmp/linux/part2/exam_2 && cd /tmp/linux/part2/exam_2
mkdir -p app logs config

sudo useradd -r -s /sbin/nologin deploy 2>/dev/null || true

# 소유자와 그룹 동시 변경
sudo chown deploy:www-data app

# 소유자만 변경 (그룹 유지)
sudo chown deploy logs

# 그룹만 변경
sudo chown :www-data config

# 디렉토리 전체 재귀 변경 (-R)
sudo chown -R deploy:www-data /tmp/linux/part2/exam_2/

ls -la

mkdir -p /tmp/linux/part2/exam_3 && cd /tmp/linux/part2/exam_3

sudo groupadd devteam 2>/dev/null || true
sudo useradd -m -s /bin/bash alice 2>/dev/null || true
sudo usermod -aG devteam alice

mkdir -p shared
sudo chgrp devteam shared
sudo chmod 2775 shared
ls -ld shared

drwxrwsr-x  2  ubuntu  devteam  4096  ...  shared

# alice가 파일 생성 후 그룹 확인
sudo -u alice touch shared/alice_report.txt
ls -la shared/

-rw-rw-r--  1  alice  devteam  0  ...  alice_report.txt

# SUID 파일 목록 (권한 상승 공격 경로)
find / -perm -4000 -type f 2>/dev/null

# world-writable 파일 (others에 쓰기 권한)
find /var/www -perm -0002 -type f 2>/dev/null

# 소유자 없는 파일 (삭제된 계정의 파일)
find /home -nouser 2>/dev/null

umask: 새 파일의 기본 권한

`umask`는 새 파일이나 디렉토리를 만들 때 자동으로 **제거할 권한 비트**를 지정합니다. "마스크"이므로 설정한 비트가 **없어지는** 권한입니다.

기본 생성 권한:

• 파일: 666 (실행 권한은 기본 부여 안 함)
• 디렉토리: 777

umask 계산은 산술 빼기가 아닌 비트 NOT AND 연산입니다. 파일 기본 퍼미션에서 umask를 비트 반전한 값과 AND를 취합니다: 기본값 & ~umask.

확대

umask 022일 때:

파일:      666 & ~022 = 644  (rw-r--r--)
디렉토리:  777 & ~022 = 755  (rwxr-xr-x)

umask 027일 때:

파일:      666 & ~027 = 640  (rw-r-----)
디렉토리:  777 & ~027 = 750  (rwxr-x---)

단순한 경우엔 빼기 결과와 같지만, umask 033처럼 교차 비트가 있으면 달라집니다. 예를 들어 666 - 033 = 633이지만 실제 동작은 666 & ~033 = 644입니다.

# 현재 umask 확인
umask
# 0022

# 기호 형식으로 확인
umask -S
# u=rwx,g=rx,o=rx

# umask 변경 (현재 세션만)
umask 027

# 테스트
touch newfile.txt && ls -la newfile.txt
# -rw-r-----  ...  (640 확인)

# 영구 변경: ~/.bashrc 또는 /etc/profile에 추가
echo "umask 027" >> ~/.bashrc

실무 가이드라인:

• 개인 개발 서버: 022 (기본값)
• 보안이 중요한 서비스 계정: 027
• 매우 민감한 환경: 077 (소유자만 접근)

서비스 계정의 umask를 강화하면 실수로 생성되는 파일의 권한 노출을 예방할 수 있습니다.

# 현재 umask 확인
umask
# 0022

# 파일 생성 후 기본 권한 확인
touch with_default_umask.txt
ls -la with_default_umask.txt
# -rw-r--r--  (644)

# umask를 027로 변경
umask 027

# 이제 새로 생성하는 파일의 권한 확인
touch with_secure_umask.txt
ls -la with_secure_umask.txt
# -rw-r-----  (640) — others는 접근 불가

# systemd 서비스에서 umask 설정 예시
# /etc/systemd/system/myapp.service 에 추가:
# [Service]
# UMask=0027

ACL: rwx만으로 부족할 때

전통적인 rwx 모델은 소유자/그룹/기타의 3단계만 지원합니다. ACL을 사용하면 **특정 사용자나 그룹에 개별적으로 권한**을 부여할 수 있습니다.

ACL이 필요한 상황:

• nginx 프로세스(www-data)는 /app/config.yml을 읽어야 하는데, 파일 소유자는 deploy 팀 계정
• 감사팀 사용자 auditor에게만 /var/log/app/의 읽기 권한 부여
• CI/CD 봇 계정이 특정 파일만 쓸 수 있도록 제한

# ACL 조회
getfacl /app/config.yml

# 예시 출력:
# file: app/config.yml
# owner: deploy
# group: deploy
# user::rw-
# group::r--
# other::---
# user:www-data:r--     ← ACL로 추가된 항목

ls -la에서 ACL이 설정된 파일은 권한 필드 끝에 + 기호가 붙습니다:

-rw-r-----+  1  deploy  deploy  1024  ...  config.yml

ACL을 사용해 특정 서비스 계정에만 파일 접근 권한을 부여합니다.

# ACL 지원 여부 확인 (파일시스템이 ACL 마운트 옵션 필요)
mount | grep -i acl
# 또는
tune2fs -l /dev/sda1 | grep "Default mount options"

# 특정 사용자에게 읽기 권한 부여
setfacl -m u:www-data:r /app/config.yml

# 특정 그룹에게 읽기+실행 권한 부여
setfacl -m g:auditors:rx /var/log/app/

# 재귀적으로 디렉토리 전체에 ACL 적용
setfacl -R -m u:www-data:rx /app/static/

# 기본 ACL 설정 (새로 생성되는 파일에도 자동 적용)
setfacl -d -m u:www-data:r /app/config/

# ACL 확인
getfacl /app/config.yml

# ACL 제거 (특정 사용자)
setfacl -x u:www-data /app/config.yml

# ACL 전체 제거
setfacl -b /app/config.yml

실무 팁: ACL 설정 후 getfacl 출력을 파일로 저장해두면 나중에 setfacl --restore로 일괄 복원할 수 있습니다.

# 디렉토리 전체 ACL 백업
getfacl -R /app/ > /backup/app_acl_backup.txt

# 복원
setfacl --restore=/backup/app_acl_backup.txt

ls -la deploy.sh

-rw-r--r--  1  ubuntu  ubuntu  ...  deploy.sh

# 소유자에게 실행 권한 추가
chmod u+x deploy.sh

# 디렉토리 진입이 안 될 때 (cd: Permission denied)
ls -ld /app/config
# drw-r--r--  (실행 권한 x 없음)
sudo chmod u+x /app/config

# 인터프리터를 직접 지정하면 chmod 없이 실행 가능
bash deploy.sh

namei -om /var/www/html/app/index.html

drwxr-xr-x  root    root   /
drwxr-xr-x  root    root   var
drwxr-xr-x  root    root   www
drwxr-xr-x  root    root   html
drw-------  deploy  deploy app     ← others에 x 없음! 여기서 차단
-rw-r--r--  deploy  deploy index.html

# 막힌 디렉토리에 실행 권한 추가
sudo chmod o+x /var/www/html/app

# 파일 자체 읽기 권한도 확인
sudo chmod 644 /var/www/html/app/index.html

mount | grep "on / "

/dev/sda1 on / type ext4 (rw,relatime)

# 임시 재마운트 (재부팅 시 초기화)
sudo mount -o remount,acl /

# 영구 설정: /etc/fstab 편집 후
# defaults,acl 추가
sudo mount -o remount /

# XFS 파일시스템은 기본적으로 ACL을 지원하므로 설정 불필요

find / -perm -4000 -type f 2>&1 | head -5

find: '/proc/tty/driver': Permission denied
find: '/proc/1234/fd': Permission denied
/usr/bin/passwd
/usr/bin/sudo

# stderr 버리기 (의사 파일시스템 노이즈 제거)
find / -perm -4000 -type f 2>/dev/null

# 또는 실제 파일시스템만 검사
find /usr /bin /sbin /opt /home -perm -4000 -type f 2>/dev/null

# 어느 경로에서 막히는지 정확히 찾기
namei -om /var/www/html/app/index.html

drw-------  deploy  deploy  app     ← 여기서 차단

# 최소 권한으로 수정
sudo chown -R deploy:www-data /var/www/html
sudo find /var/www/html -type d -exec chmod 750 {} \;
sudo find /var/www/html -type f -exec chmod 640 {} \;

# 검증
curl -I http://localhost/app/index.html

심화 — 삭제 권한은 파일이 아니라 디렉토리에 있다

# 파일이 아니라 상위 디렉토리 권한을 봐야 삭제 가능 여부를 안다
ls -ld "$(dirname /opt/app/config/app.yml)"   # 이 디렉토리의 w·x가 삭제를 좌우
namei -om /opt/app/config/app.yml             # 경로상 각 단계의 소유자·권한 확인

# root조차 못 지우게 하는 진짜 불변(immutable) — 파일 권한을 넘어선 속성 레벨
sudo chattr +i /opt/app/config/app.yml
lsattr /opt/app/config/app.yml                # ----i--------- 이면 잠김

명령어·단축키 빠른 참조

이 모듈에서 다룬 권한·소유권 명령을 실전 옵션과 함께 모았습니다.

관련 모듈로 더 깊이:

• 리눅스 다중 사용자 권한 분리와 그룹 설정 실무 — 권한 비트가 적용되는 대상인 사용자·그룹·소유권의 기반 개념
• 리눅스 부팅 시 데몬 프로세스 자동 실행 및 관리 가이드 — User=·UMask=로 서비스를 비특권 계정으로 안전하게 실행하기
• CIS 벤치마크 기반의 리눅스 OS Hardening 및 취약점 방어 — 최소 권한 원칙을 서버 전반의 보안 강화로 확장하기

다음 모듈에서는 패키지 관리 — apt와 dnf로 소프트웨어를 설치·업데이트하고 저장소를 관리하는 방법을 다룹니다.