SMALL

 

이번 챕터에서 배울것

 

Linux는 모든 파일과 디렉토리에 소유자(owner), 그룹(group), 기타(others) 세 주체에 대한 권한을 부여합니다. 

이에 대해 각 파일 별로 권한을 주었을떄 어떤 변화가 있는지 실습을 하고 이해를 해보는 시간을 가지고자 하였습니다

 

실습 환경 준비

 

#권한 확인 명령어 사전 점검
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

###실습1 실습2###
#유저 및 그룹 생성, 배치
useradd -m dev_user1
usermod -aG devteam user1
groupadd devteam

# 그룹의 권한 설정
sudo chgrp devteam /opt/shared 
OR
sudo chown root:devteam /opt/shared

#SGID 설정 
sudo chown root:devteam /opt/shared

###실습 3 ###
#chmod/chgrp 변경
sudo mkdir -p /tmp/ownership-lab/app
sudo touch /tmp/ownership-lab/app/file1
ls -l /tmp/ownership-lab/app


- 권한 체계: rwx와 숫자 표기법

 

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

-rwxr-xr--   1   deploy   www-data   4096   Mar 26 09:00   deploy.sh
│└─┬─┘└─┬─┘└─┬─┘
│  owner group others
│
└── 파일 타입: - = 일반파일, d = 디렉토리, l = 심볼릭링크
기호숫자파일에서의 의미디렉토리에서의 의미
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 — 절대 프로덕션에서 쓰면 안 됨
실습 전 find 명령어 설명
더보기 
find [검색시작경로] [조건식] [동작]

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

# / : 루트부터 전체 검색
# -perm -4000 : SUID 비트가 설정된 항목
# -type f : 일반 파일만
# 2>/dev/null : 오류 메시지(stderr) 숨김

 

2-1 이름,경로,타입 관련
옵션 의미 예시 설명
-name 이름 정확/패턴 매칭 find . -name "*.txt" 대소문자 구분
-iname 이름 패턴 매칭 find . -iname "*.TXT" 대소문자 무시
-path 전체 경로 기준 매칭 find . -path "*/cache/*" 경로 전체 비교
-ipath 경로 매칭, 대소문자 무시 find . -ipath "*/LOG/*" 대소문자 무시
-type f 일반 파일 find . -type f file
-type d 디렉터리 find . -type d directory
-type l 심볼릭 링크 find . -type l link
-type s 소켓 find . -type s socket
-type p named pipe find . -type p FIFO
-type b 블록 디바이스 find /dev -type b block device
-type c 문자 디바이스 find /dev -type c char device

2-2 권한,소유자,그룹 관련

옵션 의미 예시 설명
-perm MODE 권한이 정확히 일치 find . -perm 644 정확히 644
-perm -MODE 지정 권한 비트가 모두 포함 find / -perm -4000 SUID 포함
-perm /MODE 지정 비트 중 하나라도 포함 find . -perm /222 쓰기 비트 하나라도
-user USER 소유자 기준 검색 find /home -user user1 owner=user1
-group GROUP 그룹 기준 검색 find /srv -group devteam group=devteam
-uid UID UID 기준 검색 find / -uid 0 root 소유
-gid GID GID 기준 검색 find / -gid 1000 특정 그룹 ID

 

2-2 시간 관련

옵션 의미 기준 예시
-mtime n 내용 수정일이 정확히 n일 전 day find . -mtime 7
-mtime -n n일 이내 수정 day find . -mtime -3
-mtime +n n일 초과 경과 day find . -mtime +30
-atime 마지막 접근 시간 day find . -atime -1
-ctime inode 변경 시간 day find . -ctime -2
-mmin 내용 수정일(분 단위) minute find . -mmin -60
-amin 접근 시간(분 단위) minute find . -amin -30
-cmin 상태 변경(분 단위) minute find . -cmin -10
-newer FILE FILE보다 최근 file timestamp find . -newer ref.txt

 

논리 연산자 (검색 조건식)

연산 의미 예시 설명
-a AND find . -type f -a -name "*.sh" 둘 다 만족
-o OR find . -name "*.log" -o -name "*.txt" 둘 중 하나
! NOT find . ! -name "*.log" 부정
\( ... \) 우선순위 그룹 find . \( -name "*.log" -o -name "*.txt" \) 조건 묶기

특수 권한 비트: SUID, SGID, Sticky Bit

 

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

SUID (Set User ID) — 비트값 4000

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

bash# 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) 공격 경로가 되므로 정기적으로 검사를 진행해야한다

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

일반 사용자가 사용시 실행되는 명령어 -> 설정 값에 따라 Root 처럼 동작

 

SGID (Set Group ID) — 비트값 2000

  • 실행 파일에 설정: SUID와 동일하게 그룹 기준으로 동작
  • 디렉토리에 설정: 해당 디렉토리 안에 생성되는 모든 파일이 디렉토리의 그룹을 상속
bash# 공유 디렉토리 설정 예시
sudo chmod 2775 /opt/shared #SGID 설정 
ls -ld /opt/shared/
# drwxrwsr-x  2  root  devteam  4096  ...  /opt/shared/
#       ^
#       s = SGID 비트

Sticky Bit — 비트값 1000

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

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

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

특수 비트 숫자 표기법:
bashchmod 4755 /usr/local/bin/mytool   # SUID + 755
chmod 2775 /opt/shared             # SGID + 775
chmod 1777 /tmp                    # Sticky + 777

 

chmod u-s,g-s,o-t /opt/shared/

#SUID, SGID,Sticky bit 삭제

기본 실습

Step 1. 현재 디렉토리 권한 상세 확인

 

ls -la 명령으로 파일의 권한, 링크 수, 소유자, 그룹, 크기, 수정 시각을 확인합니다. 첫 번째 문자(파일 타입)부터 마지막 3자(others 권한)까지 한 줄씩 읽는 연습을 합니다.

bash# 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

 

세 파일의 권한 차이에 주목하세요. shadow는 root 그룹 구성원만 읽을 수 있고, passwd 실행 파일에는 SUID(s)가 설정되어 있습니다.

ls -la
Step 2. chmod 심볼릭 모드로 권한 추가/제거

 

숫자 모드 외에 심볼릭 모드를 사용하면 현재 권한에서 특정 부분만 변경할 수 있어 실수를 줄일 수 있습니다.

bash# 테스트 파일 준비
mkdir -p /tmp/linux/part1/exam_1/ && cd /tmp/linux/part1/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

 

심볼릭 모드 연산자:

  • + — 권한 추가
  • - — 권한 제거
  • = — 정확히 지정한 권한으로 덮어씀

대상 지정자: u(owner), g(group), o(others), a(all = ugo)

bashchmod u+x,g-w,o=r script.sh
Step 3. chown과 chgrp으로 소유권 변경

 

소유자와 그룹을 따로 또는 함께 변경하는 방법을 익힙니다. chgrp은 그룹만 변경할 때 사용합니다.

bash# 소유자와 그룹을 동시에 변경
sudo chown deploy:www-data /var/www/html/app

# 소유자만 변경 (그룹 유지)
sudo chown deploy /var/www/html/app

# 그룹만 변경 (chgrp 사용)
sudo chgrp www-data /var/www/html/app

# 그룹만 변경 (chown 사용, 콜론 앞을 비움)
sudo chown :www-data /var/www/html/app

# 재귀적으로 디렉토리 전체 변경 (-R 플래그)
sudo chown -R deploy:www-data /var/www/html/

 

주의: -R 플래그 사용 시 경로를 반드시 두 번 확인하세요. 잘못된 경로에 -R을 적용하면 복구가 어렵습니다.
bashsudo chown deploy:www-data /var/www/html/app
Step 4. SGID로 팀 공유 디렉토리 설정

 

여러 팀원이 파일을 공유하는 디렉토리를 설정할 때 SGID를 활용합니다. SGID가 없으면 각자 만든 파일의 그룹이 개인 기본 그룹으로 설정되어 다른 팀원이 접근하지 못하는 문제가 생깁니다.

bash# 팀 그룹 생성 및 사용자 추가
sudo groupadd devteam
sudo usermod -aG devteam alice
sudo usermod -aG devteam bob

# 공유 디렉토리 생성 및 SGID 설정
sudo mkdir -p /opt/shared
sudo chgrp devteam /opt/shared
sudo chmod 2775 /opt/shared
ls -ld /opt/shared
# drwxrwsr-x  2  root  devteam  4096  ...  /opt/shared

# alice가 파일 생성 후 그룹 확인
su - alice -c "touch /opt/shared/alice_report.txt"
ls -la /opt/shared/
# -rw-rw-r--  1  alice  devteam  0  ...  alice_report.txt
#                        ^^^^^^^
#                        alice의 기본 그룹이 아닌 devteam 상속

 

SGID 덕분에 alice가 만든 파일도 devteam 그룹으로 생성되어 bob이 접근할 수 있습니다.

bashsudo chmod 2775 /opt/shared && sudo chgrp devteam /opt/shared
Step 5. 보안 감사: 위험한 권한 파일 탐색

 

/dev/null"> 정기 보안 감사 시 SUID/SGID 파일 목록과 world-writable 파일을 점검합니다.

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

# SGID 파일 목록
find / -perm -2000 -type f 2>/dev/null

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

# world-writable 디렉토리 (sticky bit 없는 것만)
find / -type d -perm -0002 ! -perm -1000 2>/dev/null

# 소유자 없는 파일 (삭제된 사용자의 파일)
find / -nouser -o -nogroup 2>/dev/null

 

발견된 SUID 파일은 OS 기본 제공 목록과 비교해 예상치 못한 항목이 있으면 즉시 조사합니다.

 

umask — 파일 생성 시 빠지는 권한

 

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

 

기본 생성 권한:

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

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---)
bash# 현재 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 (소유자만 접근)
Step 6. umask 동작 확인 및 서비스 계정 설정

 

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

bash# 현재 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
bashumask 027 && touch test_secret.conf && ls -la test_secret.conf

ACL: rwx만으로 부족할 때

ACL (Access Control List) — 세밀한 권한 제어

 

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

 

ACL이 필요한 상황:

  • nginx 프로세스(www-data)는 /app/config.yml을 읽어야 하는데, 파일 소유자는 deploy 팀 계정
  • 감사팀 사용자 auditor에게만 /var/log/app/의 읽기 권한 부여
  • CI/CD 봇 계정이 특정 파일만 쓸 수 있도록 제한
bash# 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
Step 7. getfacl과 setfacl로 ACL 설정

 

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

bash# 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로 일괄 복원할 수 있습니다.

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

# 복원
setfacl --restore=/backup/app_acl_backup.txt
bashsetfacl -m u:www-data:r /app/config.yml

트러블슈팅

Permission denied: 스크립트가 실행되지 않음

 

실행 권한이 없거나, 스크립트의 shebang 인터프리터에 실행 권한이 없는 경우입니다.

bash# 증상
./deploy.sh
# bash: ./deploy.sh: Permission denied

# 진단
ls -la deploy.sh
# -rw-r--r--  1  ubuntu  ubuntu  ...  deploy.sh
#  ^^^
#  x 비트가 없음

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

# 또는 명시적으로 인터프리터 지정해서 실행 (chmod 없이도 동작)
bash deploy.sh

# 디렉토리 실행 권한이 없는 경우 (cd가 안 됨)
cd /app/config
# bash: cd: /app/config: Permission denied

ls -ld /app/config
# drw-r--r--  (x 비트 없음)

sudo chmod u+x /app/config

shebang 관련 오류는 #!/usr/bin/env python3 경로에 실행 권한이 있는지도 확인하세요.

 

트러블슈팅

nginx/apache가 403 Forbidden 반환

웹 서버가 파일을 제공하지 못하는 원인은 대부분 세 가지 권한 문제입니다.

bash# 1. 웹 루트 경로의 각 디렉토리에 실행(x) 권한 확인
namei -om /var/www/html/app/index.html
# f: /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

# 2. 파일 자체의 읽기 권한 확인
ls -la /var/www/html/app/index.html
# -rw-------  (others에 r 없음)

sudo chmod 644 /var/www/html/app/index.html

# 3. SELinux 컨텍스트 문제 (RHEL/CentOS 환경)
ls -laZ /var/www/html/app/
sudo restorecon -R /var/www/html/app/

 

namei -om [경로]는 경로의 각 구성 요소 권한을 한 번에 보여주는 매우 유용한 디버깅 도구입니다.

 

트러블슈팅

sudo: command not found / sudo 없이 root 파일 수정 시도

서비스 계정이나 컨테이너 환경에서 자주 발생합니다.

bash# 증상: sudo가 없는 환경
sudo chown www-data /var/log/app.log
# sudo: command not found

# 현재 사용자 확인
whoami && id

# sudo 그룹 멤버십 확인
groups ubuntu
# ubuntu : ubuntu adm sudo docker  ← sudo 그룹 있으면 sudo 사용 가능

# sudo 없이 root 작업이 필요하면 su 사용
su -c "chown www-data:www-data /var/log/app.log"

# 컨테이너 환경에서 root로 실행 후 권한 설정
docker exec -u root mycontainer chown www-data:www-data /var/log/app.log

# 실수로 sudo 권한을 잃었을 때 복구
# 단일 사용자 모드로 부팅 후:
usermod -aG sudo username

 

트러블슈팅

setfacl: Operation not supported

파일시스템이 ACL을 지원하지 않도록 마운트되어 있거나, 파일시스템 자체가 ACL을 지원하지 않는 경우입니다.

bash# 증상
setfacl -m u:www-data:r /app/config.yml
# setfacl: /app/config.yml: Operation not supported

# 원인 확인: 마운트 옵션에 acl이 있는지 확인
mount | grep "on / "
# /dev/sda1 on / type ext4 (rw,relatime)
#                                ^^^
#                                acl 옵션 없음

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

# 해결 2: /etc/fstab에 acl 옵션 추가 (영구)
# /dev/sda1  /  ext4  defaults,acl  0 1
# 편집 후:
sudo mount -o remount /

# ext4의 경우 기본 마운트 옵션에 acl 추가
sudo tune2fs -o acl /dev/sda1

# XFS는 기본적으로 ACL 지원, 별도 설정 불필요

실무 맥락

 

신규 마이크로서비스 배포 시 권한 설계

 

새로운 Python 백엔드 서비스를 배포할 때 서비스 계정과 권한을 올바르게 설계하는 과정입니다. 잘못된 권한은 보안 취약점이 되고, 너무 좁은 권한은 런타임 에러의 원인이 됩니다.

bash# 1. 전용 서비스 계정 생성 (로그인 비활성화)
sudo useradd --system --no-create-home --shell /sbin/nologin myapp

# 2. 애플리케이션 디렉토리 구조와 권한
sudo mkdir -p /opt/myapp/{bin,config,logs,tmp}

# 실행 파일: root 소유, 서비스 계정은 실행만
sudo chown root:myapp /opt/myapp/bin/myapp-server
sudo chmod 750 /opt/myapp/bin/myapp-server

# 설정 파일: root 소유, 서비스 계정은 읽기만 (비밀 포함)
sudo chown root:myapp /opt/myapp/config/app.yml
sudo chmod 640 /opt/myapp/config/app.yml

# 로그 디렉토리: 서비스 계정이 쓰기 가능
sudo chown myapp:myapp /opt/myapp/logs
sudo chmod 750 /opt/myapp/logs

# 임시 파일 디렉토리: 서비스 계정 전용
sudo chown myapp:myapp /opt/myapp/tmp
sudo chmod 700 /opt/myapp/tmp

# 3. ACL로 운영팀에게 로그 읽기 권한 부여 (소유권 변경 없이)
sudo setfacl -m g:ops-team:rx /opt/myapp/logs
sudo setfacl -d -m g:ops-team:r /opt/myapp/logs

# 4. 결과 검증
ls -la /opt/myapp/
getfacl /opt/myapp/logs

# 5. 서비스 계정 umask 설정 (systemd 서비스 파일)
# [Service]
# User=myapp
# Group=myapp
# UMask=0027

 

이 패턴을 따르면 서비스가 침해되어도 공격자는 설정 파일과 시스템을 수정할 수 없고, 로그만 읽거나 /opt/myapp/tmp 안에서만 파일을 만들 수 있습니다.

 

실무 맥락

 

인시던트 대응: 파일 권한 문제로 인한 서비스 장애

새벽 2시에 알림이 옵니다. 배포 직후부터 앱이 설정 파일을 읽지 못해 시작에 실패하고 있습니다.

bash# 1. 서비스 상태와 오류 로그 확인
systemctl status myapp.service
journalctl -u myapp.service --since "10 minutes ago"
# ... PermissionError: [Errno 13] Permission denied: '/opt/myapp/config/app.yml'

# 2. 파일 권한 즉각 진단
ls -la /opt/myapp/config/app.yml
# -rw-------  1  deploy  deploy  2048  ...  app.yml
#  ^^^^^^
#  deploy만 읽을 수 있음 — myapp 서비스 계정은 접근 불가

ls -la /opt/myapp/config/
# drwx------  2  deploy  deploy  ...  config/
#  ^^^
#  디렉토리 진입 자체가 불가

# 3. 배포 스크립트에서 chown이 빠진 것 확인
# (원인: 배포 시 파일을 deploy 계정으로 복사 후 chown 단계 누락)

# 4. 즉각 복구
sudo chown root:myapp /opt/myapp/config/app.yml
sudo chmod 640 /opt/myapp/config/app.yml
sudo chown root:myapp /opt/myapp/config/
sudo chmod 750 /opt/myapp/config/

# 5. 서비스 재시작 및 확인
sudo systemctl start myapp.service
systemctl status myapp.service

# 6. 배포 스크립트에 권한 설정 단계 추가 (재발 방지)
# deploy.sh 마지막에:
# sudo chown -R root:myapp /opt/myapp/config/
# sudo chmod 750 /opt/myapp/config/
# sudo chmod 640 /opt/myapp/config/*.yml

 

이 인시던트의 교훈: 배포 파이프라인에 "권한 검증 단계"를 추가하면 프로덕션 장애를 사전에 막을 수 있습니다. namei -om [경로] 명령을 배포 검증 스크립트에 포함시키는 것이 좋습니다.

핵심 요약

개념명령실무 사용 빈도

권한 확인 ls -la, stat 매일
숫자 모드 변경 chmod 755 파일 매일
심볼릭 모드 변경 chmod u+x,g-w 파일 자주
소유자/그룹 변경 chown user:group 파일 자주
그룹만 변경 chgrp group 파일 가끔
umask 확인/설정 umask 027 서비스 설계 시
SUID 설정 chmod 4755 파일 드물게 (신중히)
SGID 설정 chmod 2775 디렉토리 공유 디렉토리 설계 시
Sticky bit 설정 chmod 1777 디렉토리 공유 임시 디렉토리
ACL 조회 getfacl 파일 rwx 부족할 때
ACL 설정 setfacl -m u:user:r 파일 정교한 권한 제어 시
경로 권한 추적 namei -om /경로 403 오류 디버깅 시
SUID 파일 탐색 find / -perm -4000 -type f 보안 감사 시

 

다음 단계로는 SELinux/AppArmor (MAC, Mandatory Access Control)를 학습하면 파일 권한보다 훨씬 강력한 접근 제어를 구현할 수 있습니다.

 

 

인프라를 학습하고 싶다면?

반응형
LIST

'Linux' 카테고리의 다른 글

터미널 접속 & 기본 조작  (0) 2026.05.22
Linux 소개 & 왜 배워야 하나  (0) 2026.05.21
[Linux]Grafana Alloy 및 Prometheus & Loki 연동  (0) 2025.06.17
[Linux] Docker  (0) 2025.03.20
[Devops] Ansible 실습  (0) 2025.03.13

티스토리툴바