🚨INCIDENT ALERT

HIGH

새벽 1시, 배포 직후 모니터링 알림이 울렸습니다. 앱이 설정 파일을 읽지 못해 시작에 실패하고 있습니다. 로그를 보니 PermissionError: [Errno 13] Permission denied: '/opt/myapp/config/app.yml'. 배포 스크립트에서 파일을 복사한 뒤 chown 단계를 빠뜨렸고, 서비스 계정이 설정 파일에 접근하지 못하는 상황입니다.

ls -la 한 줄로 문제가 어디에 있는지 보이고, chmod + chown 두 줄로 해결됩니다. 파일 권한 체계를 이해하면 Permission denied가 더 이상 미스터리가 아닙니다.

파일 권한 (File Permissions)

이번 챕터에서 배울 것

1ls -la 출력을 읽고 rwx 권한과 소유자·그룹·기타 구분을 설명할 수 있다
2chmod로 숫자 모드와 심볼릭 모드를 사용해 권한을 변경할 수 있다
3chown, chgrp으로 파일의 소유자와 그룹을 변경할 수 있다
4SUID, SGID, Sticky Bit의 동작을 이해하고 공유 디렉토리를 설계할 수 있다
5umask로 새 파일의 기본 권한을 제어하고 ACL로 세밀한 권한을 부여할 수 있다

실습 환경 준비

권한 확인 명령어 사전 점검

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

ACL 도구 설치 여부 확인

which getfacl setfacl || sudo apt-get install -y acl

실습용 테스트 파일 생성

touch ~/test-perms.sh && mkdir -p ~/shared-dir

현재 umask 값 확인

umask

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

-rwxr-xr--   1   deploy   www-data   4096   Mar 26 09:00   deploy.sh
│└─┬─┘└─┬─┘└─┬─┘
│  owner group others
│
└── 파일 타입: - = 일반파일, d = 디렉토리, l = 심볼릭링크

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

기호	숫자	파일에서의 의미	디렉토리에서의 의미
`r`	4	파일 내용 읽기	디렉토리 목록 조회 (`ls`)
`w`	2	파일 내용 수정	디렉토리 안에 파일 생성/삭제
`x`	1	파일 실행	디렉토리 진입 (`cd`)
`-`	0	권한 없음	권한 없음

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

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 — 절대 프로덕션에서 쓰면 안 됨

파일 권한 구조 — ls -la 읽기, rwx→숫자 변환, 실무 조합, 특수 비트

일반 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

1권한 읽기 & chmod 연습

세 파일의 권한 차이를 비교하면서 ls -la 출력을 읽는 법을 익힙니다.

로컬 터미널

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

OUTPUT

-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

shadow는 root 그룹만 읽을 수 있고, passwd 실행 파일에는 SUID(s)가 설정되어 있습니다.

로컬 터미널

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

OUTPUT

-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

OUTPUT

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

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

🔍실행 후 확인할 것

/etc/passwd 는 -rw-r--r-- (644) — 누구나 읽을 수 있지만 쓸 수 없습니다
/etc/shadow 는 -rw-r----- (640) — root 그룹만 읽을 수 있습니다
/usr/bin/passwd 의 s 는 SUID 비트 — root 권한으로 실행됨을 의미합니다
chmod u+x,g=rx,o-rwx 처럼 콤마로 여러 변경을 한 번에 적용할 수 있습니다

2chown으로 소유자·그룹 변경

배포 계정과 웹서버 계정이 디렉토리를 공유하는 실무 패턴을 연습합니다.

로컬 터미널

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

sudo chown deploy:www-data app

🔍실행 후 확인할 것

chown user:group 형식으로 소유자와 그룹을 동시에 변경합니다
chown :group 처럼 콜론 앞을 비우면 그룹만 변경됩니다
-R 옵션은 하위 모든 파일/디렉토리에 재귀 적용합니다 — 경로를 두 번 확인하세요

3SGID로 팀 공유 디렉토리 설정

SGID를 설정하면 공유 디렉토리에 생성된 파일이 디렉토리의 그룹을 자동 상속합니다.

로컬 터미널

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

OUTPUT

drwxrwsr-x  2  ubuntu  devteam  4096  ...  shared

로컬 터미널

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

OUTPUT

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

alice의 기본 그룹이 아닌 devteam 이 자동 설정됩니다.

sudo chmod 2775 shared

🔍실행 후 확인할 것

ls -ld 출력에서 그룹 실행 권한 위치에 s 가 보이면 SGID가 설정된 것입니다
SGID 없이 alice 가 파일을 만들면 alice 의 기본 그룹이 설정되어 bob 이 접근하지 못합니다
chmod 2775 = SGID(2000) + rwxrwxr-x(775) 입니다

4보안 감사 — SUID 파일 목록 확인

정기 보안 감사에서 SUID/SGID 파일과 world-writable 파일을 점검합니다.

로컬 터미널

# 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

find / -perm -4000 -type f 2>/dev/null

🔍실행 후 확인할 것

find 결과를 파일로 저장해두면 다음 감사 시 diff 로 변경 사항을 추적할 수 있습니다
예상치 못한 SUID 파일이 나타나면 권한 상승 공격 경로일 수 있으므로 즉시 조사합니다
2>/dev/null 은 /proc, /sys 같은 의사 파일시스템의 Permission denied 오류를 숨깁니다

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

상황: 스크립트를 실행하려는데 위 오류가 납니다. 분명히 파일이 있는데 왜 실행이 안 될까요?

원인: 파일에 실행 권한(x)이 없거나, 현재 사용자가 파일 소유자가 아니라 실행 권한을 가진 주체(owner/group/others)에 해당하지 않습니다.

진단:

로컬 터미널

ls -la deploy.sh

OUTPUT

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

권한 문자열에 x 가 하나도 없습니다.

해결:

로컬 터미널

# 소유자에게 실행 권한 추가
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

상황: Nginx가 /var/www/html/app/index.html을 제공하지 못하고 403 Forbidden을 반환합니다.

원인: 웹 서버(www-data)가 파일에 도달하려면 경로 상의 모든 디렉토리에 실행(x) 권한이 있어야 합니다. 중간 디렉토리 하나라도 막혀 있으면 파일 자체의 권한과 무관하게 403이 발생합니다.

진단:

로컬 터미널

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

OUTPUT

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

상황: setfacl 로 ACL을 설정하려는데 위 오류가 납니다.

원인: 파일시스템이 acl 마운트 옵션 없이 마운트되어 있습니다. ext4의 경우 기본적으로 ACL이 비활성화된 배포판이 있습니다.

진단:

로컬 터미널

mount | grep "on / "

OUTPUT

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

acl 옵션이 없습니다.

해결:

로컬 터미널

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

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

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

상황: 보안 감사 중 find / -perm -4000 -type f 를 실행했는데 /proc, /sys 같은 의사 파일시스템에서 Permission denied 가 수천 줄 쏟아집니다. 실제 SUID 파일을 찾기 어렵고 CI 파이프라인도 종료 코드 1로 실패합니다.

원인: /proc, /sys, /run 은 실제 파일시스템이 아닌 커널 가상 파일시스템으로, 일반 사용자가 접근할 수 없는 경로가 많습니다. find 는 이 경로에서 Permission denied 를 만나면 에러를 출력하고 계속 진행합니다.

진단:

로컬 터미널

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

OUTPUT

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

상황: 웹 서버가 파일을 제공하지 못해 빠르게 chmod -R 777 /var/www 를 실행했습니다. 당장은 동작했지만, 보안 감사에서 지적을 받았고 이후 업로드 디렉토리를 통해 웹쉘이 심어지는 인시던트가 발생했습니다.

원인: chmod 777 은 누구나 파일을 생성·실행할 수 있게 만듭니다. 업로드 디렉토리에 이것이 적용되면 공격자가 PHP 웹쉘을 업로드해 서버 전체를 장악할 수 있습니다.

진단:

로컬 터미널

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

OUTPUT

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

💼

실무 맥락스타트업 SRE 팀에 합류한 첫 주, 팀 리드가 '새 결제 서비스 배포 전에 권한 설계 리뷰해줘'라고 합니다. 현재 모든 서비스가 root로 실행 중입니다.

현업 패턴

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

[Linux] chmod/chown으로 파일 읽기·쓰기·실행 권한 완벽 제어

파일 권한 (File Permissions)

umask: 새 파일의 기본 권한

ACL: rwx만으로 부족할 때

퀴즈 — 5문제

systemd — 나만의 서비스 등록

이것도 배워보세요