리눅스 권한 체계: chmod와 chown

"권한(Permission)이 없습니다"

리눅스 초보 시절, 뭐만 하면 Permission denied가 떴습니다. 파일 읽으려고 해도, 스크립트 실행하려고 해도, 심지어 폴더 들어가려고 해도 그 메시지만 날 괴롭혔죠.

그때 선배가 알려준 마법의 주문: "안되면 chmod 777 때려봐." 진짜 다 되더군요. 저는 그게 해결책인 줄 알았습니다. (나중에 보안 팀한테 혼나기 전까진요.)

지금 생각하면 아찔합니다. chmod 777은 "우리 집 대문 활짝 열어두고 비밀번호도 현관에 붙여두기"와 같은 짓이었으니까요.

왜 이걸 공부하게 됐나

Docker 컨테이너에서 볼륨 마운트하면 자꾸 권한 에러가 나는 거예요. 로그 파일 못 쓰고, 설정 파일 못 읽고. 매번 sudo로 땜빵하다가 "이거 제대로 이해 안 하면 계속 막힐 것 같다"는 생각이 들었습니다.

그래서 리눅스 권한 체계를 파헤쳐봤어요. rwx가 뭔지, 숫자 755가 무슨 뜻인지, chmod와 chown의 차이가 뭔지. 막연했던 게 명확해지니까, 에러 메시지 보는 순간 "아, 이 권한 문제구나" 딱 보이더라고요.

처음엔 이게 혼란스러웠다

ls -l 치면 이런 게 나옵니다.

-rw-r--r-- 1 ubuntu dev   1024 Feb  6 12:34 config.txt
drwxr-xr-x 2 ubuntu dev   4096 Feb  6 12:35 logs

뭔가 규칙이 있을 것 같은데 외계어처럼 보였어요. -rw-r--r--은 뭐고, 왜 숫자 1024도 있고, ubuntu dev는 또 뭔가요?

특히 헷갈렸던 건 폴더의 x 권한이었습니다. "실행 권한이 있어야 폴더에 들어갈 수 있다"는 게 처음엔 이해가 안 갔어요. 폴더는 프로그램도 아닌데 왜 실행 권한이 필요한 거지?

그리고 chmod 644는 되는데 chmod 777은 위험하다는데, 왜 그런지 명확히 와닿지 않았습니다.

결국 이렇게 이해했다

아파트 건물로 비유하면 딱이다

리눅스 파일 시스템을 아파트 건물로 생각하니까 와닿았습니다.

• Owner (주인): 집 소유자. 집 마음대로 꾸미고, 물건 갖다놓고, 문 열고 닫고 다 할 수 있죠.
• Group (같은 층 이웃): 같은 층 사는 사람들. 복도 청소기는 같이 쓰지만, 남의 집 냉장고는 못 열잖아요.
• Others (외부인): 택배 기사님, 방문객. 현관 앞까지만 오고, 집 안 함부로 못 들어옵니다.

이 3계층 구조가 리눅스 권한의 핵심입니다.

rwx가 뭔지 이해했다

리눅스에서 파일(또는 폴더)에 할 수 있는 행동은 딱 3가지입니다.

• r (Read, 4): 읽기
  • 파일: 내용을 볼 수 있다.
  • 폴더: ls 명령어로 목록을 볼 수 있다.
• w (Write, 2): 쓰기
  • 파일: 내용을 수정하거나 삭제할 수 있다.
  • 폴더: 폴더 안에 파일을 만들거나 삭제할 수 있다.
• x (Execute, 1): 실행
  • 파일: 프로그램으로 실행할 수 있다.
  • 폴더: 폴더 안으로 진입할 수 있다 (cd 명령어).

폴더에 x 권한이 없으면 cd 자체가 안 됩니다. 이게 와닿았던 이유는, "아파트 복도에 진입 권한이 없으면 복도에 뭐가 있든 못 들어간다"로 받아들였기 때문이에요.

숫자의 비밀 - 4+2+1 조합

rwx를 숫자로 바꾸는 게 처음엔 신기했는데, 결국 이거였습니다.

• r = 4
• w = 2
• x = 1

더하면 됩니다.

• rwx = 4 + 2 + 1 = 7 (읽고, 쓰고, 실행 다 됨)
• rw- = 4 + 2 + 0 = 6 (읽고, 쓰기만. 실행 불가)
• r-x = 4 + 0 + 1 = 5 (읽고, 실행만. 수정 불가)
• r-- = 4 + 0 + 0 = 4 (읽기만)
• --- = 0 + 0 + 0 = 0 (아무것도 못 함)

예를 들어, 755는:

• 주인: 7 (rwx) - 모든 권한
• 그룹: 5 (r-x) - 읽기, 실행 가능
• 외부인: 5 (r-x) - 읽기, 실행 가능

반대로 ls -l에서 -rwxr-xr-x를 보면, "아, 755 권한이구나" 바로 알 수 있습니다.

ls -l 출력 해석하기

$ ls -l
-rw-r--r-- 1 ubuntu dev   1024 Feb  6 12:34 config.txt
drwxr-xr-x 2 ubuntu dev   4096 Feb  6 12:35 logs
-rwxr-xr-x 1 ubuntu www  12288 Feb  6 12:36 deploy.sh

각 열의 의미를 정리해본다.

1. 첫 글자: -는 파일, d는 디렉토리.
2. 다음 9글자: rwx 3개씩 (Owner / Group / Others).
3. 숫자: 하드링크 개수 (신경 안 써도 됨).
4. 이름 2개: ubuntu dev - 주인과 그룹.
5. 바이트 크기: 파일 크기.
6. 날짜/시간: 마지막 수정 시각.
7. 파일 이름.

config.txt는 rw-r--r-- (644):

• 주인(ubuntu): 읽고 쓸 수 있음.
• 그룹(dev): 읽기만 가능.
• 외부인: 읽기만 가능.

logs 폴더는 rwxr-xr-x (755):

• 주인: 읽고, 쓰고, 폴더 진입 가능.
• 그룹: 읽고, 폴더 진입 가능 (파일 생성은 못 함).
• 외부인: 읽고, 폴더 진입 가능.

deploy.sh 스크립트는 rwxr-xr-x (755):

• 주인: 읽고, 수정하고, 실행 가능.
• 그룹(www): 읽고, 실행만 가능.
• 외부인: 읽고, 실행만 가능.

chmod: 권한 바꾸기

숫자 방식 (절대 권한)

가장 직관적인 방법입니다.

$ chmod 755 deploy.sh
# 주인 - rwx(7), 그룹: r-x(5), 외부인: r-x(5)

$ chmod 644 config.txt
# 주인 - rw-(6), 그룹: r--(4), 외부인: r--(4)

$ chmod 600 ~/.ssh/id_rsa
# SSH 개인키는 주인만 읽고 쓸 수 있어야 함
# 그룹과 외부인: ---(0)

SSH 키 권한이 잘못되면 SSH가 "권한이 너무 느슨하다"며 거부합니다. 실제로 chmod 644 ~/.ssh/id_rsa 하면 ssh 명령어가 "UNPROTECTED PRIVATE KEY FILE!" 에러를 내뱉습니다.

기호 방식 (상대 권한)

기존 권한에서 일부만 수정하고 싶을 때 씁니다.

$ chmod u+x script.sh
# User(주인)에게 eXecute 권한 추가

$ chmod g-w config.txt
# Group에게서 Write 권한 제거

$ chmod o-rwx secret.txt
# Others(외부인)에게서 모든 권한 제거

$ chmod a+r readme.txt
# All(주인+그룹+외부인) 모두에게 Read 권한 추가

• u = User (Owner)

• g = Group

• o = Others

• a = All

• + = 권한 추가

• - = 권한 제거

• = = 권한 설정 (기존 권한 무시)

예를 들어:

$ chmod u=rwx,g=rx,o=r script.sh
# 주인 - rwx, 그룹: r-x, 외부인: r--
# 숫자로 치면 754

재귀적 권한 변경

폴더 안의 모든 파일/폴더에 적용하려면 -R 옵션을 씁니다.

$ chmod -R 755 /var/www/html
# 웹 서버 디렉토리 전체를 755로 설정

주의: -R은 강력한 만큼 조심해야 합니다. 잘못 쓰면 시스템 파일 권한 망가질 수 있어요.

chown: 주인 바꾸기

기본 사용법

$ chown ubuntu config.txt
# config.txt의 주인을 ubuntu로 변경

$ chown ubuntu:dev config.txt
# 주인은 ubuntu, 그룹은 dev로 변경

$ chown :www deploy.sh
# 그룹만 www로 변경 (주인은 그대로)

실제 시나리오 - 웹 서버 권한 설정

Nginx나 Apache 웹 서버는 보통 www-data 유저로 실행됩니다.

$ sudo chown -R www-data:www-data /var/www/html
$ sudo chmod -R 755 /var/www/html

이렇게 하면:

• 웹 서버가 파일을 읽고 실행할 수 있고,
• 외부인은 읽기만 가능(쓰기 불가)해서 안전합니다.

만약 웹 서버가 로그 파일을 써야 한다면:

$ sudo chown www-data:www-data /var/log/nginx
$ sudo chmod 755 /var/log/nginx

chgrp: 그룹만 바꾸기

chown :그룹 대신 chgrp를 써도 됩니다.

$ chgrp dev config.txt
# config.txt의 그룹을 dev로 변경

실제에선 chown :dev config.txt가 더 자주 쓰이긴 합니다.

Docker 볼륨 권한 문제 - 내가 겪은 실제 사례

Docker 컨테이너 안에서 파일을 만들면, 호스트에서 그 파일에 접근 못 할 때가 있습니다.

$ docker run -v $(pwd)/data:/app/data myapp
# 컨테이너 안에서 /app/data/output.log 생성

컨테이너 안에선 root로 실행되는데, 호스트에선 내가 ubuntu 유저라서 권한 충돌이 생기는 거예요.

해결법:

# Dockerfile에서 유저 지정
RUN useradd -m -u 1000 appuser
USER appuser

또는 호스트에서:

$ sudo chown -R $(whoami):$(whoami) ./data

이런 삽질을 몇 번 겪고 나니, "컨테이너와 호스트의 UID/GID가 일치해야 한다"는 개념이 와닿았습니다.

특수 권한: SUID, SGID, Sticky Bit

SUID (Set User ID)

파일 실행 시, 주인의 권한으로 실행됩니다.

$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 68208 /usr/bin/passwd

s가 보이죠? 이게 SUID입니다. passwd 명령어는 /etc/shadow를 수정해야 하는데, 이 파일은 root만 쓸 수 있어요. SUID 덕분에 일반 유저가 passwd 실행하면 root 권한으로 실행돼서 비밀번호 변경이 가능합니다.

$ chmod u+s script.sh
# 또는
$ chmod 4755 script.sh

숫자 맨 앞에 4를 붙이면 SUID입니다.

SGID (Set Group ID)

파일 실행 시, 그룹 권한으로 실행됩니다. 폴더에 SGID를 걸면, 그 폴더 안에 생성되는 모든 파일이 폴더의 그룹을 상속받습니다.

$ chmod g+s shared_folder
# 또는
$ chmod 2755 shared_folder

숫자 맨 앞에 2를 붙이면 SGID입니다.

예를 들어, 팀 프로젝트 폴더:

$ mkdir /project
$ chgrp dev /project
$ chmod 2775 /project

이제 누가 /project 안에 파일을 만들든, 그 파일의 그룹은 자동으로 dev가 됩니다.

Sticky Bit

폴더에 설정하면, 폴더 안의 파일은 주인만 삭제할 수 있습니다. /tmp 폴더가 대표적입니다.

$ ls -ld /tmp
drwxrwxrwt 10 root root 4096 /tmp

맨 끝에 t가 보이죠? Sticky bit입니다. 누구나 /tmp에 파일을 만들 수 있지만, 남이 만든 파일은 못 지웁니다.

$ chmod +t shared_folder
# 또는
$ chmod 1777 shared_folder

숫자 맨 앞에 1을 붙이면 Sticky bit입니다.

umask: 기본 권한 설정

파일을 새로 만들 때 자동으로 적용되는 권한이 있습니다. 이게 umask입니다.

$ umask
0022

umask는 "빼는" 개념입니다.

• 파일 기본 권한: 666 (rw-rw-rw-)
• 폴더 기본 권한: 777 (rwxrwxrwx)

umask 0022는:

• 파일: 666 - 022 = 644 (rw-r--r--)
• 폴더: 777 - 022 = 755 (rwxr-xr-x)

실제로 확인해볼까요?

$ umask 0022
$ touch newfile.txt
$ mkdir newfolder
$ ls -l
-rw-r--r-- 1 ubuntu dev    0 newfile.txt
drwxr-xr-x 2 ubuntu dev 4096 newfolder

딱 644, 755로 생성됐습니다.

만약 umask 0077로 바꾸면:

$ umask 0077
$ touch private.txt
$ ls -l private.txt
-rw------- 1 ubuntu dev 0 private.txt

주인만 읽고 쓸 수 있는 파일이 됩니다.

umask는 보통 ~/.bashrc나 ~/.zshrc에 설정해둡니다.

# ~/.bashrc
umask 0022

구체적인 예제 - SSH 키 권한

SSH 개인키는 반드시 600 권한이어야 합니다.

$ chmod 600 ~/.ssh/id_rsa
$ ls -l ~/.ssh/id_rsa
-rw------- 1 ubuntu ubuntu 1679 ~/.ssh/id_rsa

만약 권한이 잘못되면:

$ chmod 644 ~/.ssh/id_rsa
$ ssh user@server
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/ubuntu/.ssh/id_rsa' are too open.

SSH는 "개인키가 남에게 노출되면 안 된다"는 원칙 때문에, 권한이 느슨하면 아예 거부합니다.

공개키는 644로 해도 됩니다.

$ chmod 644 ~/.ssh/id_rsa.pub

구체적인 예제 - 웹 서버 권한 설정

Nginx 웹 서버를 운영한다고 가정해봤다.

$ sudo chown -R www-data:www-data /var/www/html
$ sudo find /var/www/html -type f -exec chmod 644 {} \;
$ sudo find /var/www/html -type d -exec chmod 755 {} \;

이렇게 하면:

• 파일: 644 (주인만 쓰기 가능, 나머지는 읽기만)
• 폴더: 755 (주인만 쓰기 가능, 나머지는 읽기+진입)

웹 서버가 업로드 폴더에 파일을 써야 한다면:

$ sudo chmod 775 /var/www/html/uploads
$ sudo chown www-data:www-data /var/www/html/uploads

이제 웹 서버가 uploads 폴더에 파일을 쓸 수 있습니다.

chmod 777이 위험한 진짜 이유

777은 "너도 나도 쟤도, 읽고 쓰고 지우고 실행까지 맘대로 해라"라는 뜻입니다.

예를 들어, 웹 서버 설정 파일이 777이라면:

$ chmod 777 /etc/nginx/nginx.conf

이러면:

• 해커가 SSH로 침투해서, nginx.conf를 수정해서 악성 코드를 심을 수 있고,
• 심지어 x 권한까지 있으니 스크립트를 실행할 수도 있습니다.

실제로 제가 예전에 Docker 컨테이너에서 Permission denied 에러가 자꾸 나니까, 귀찮아서 chmod -R 777 /app을 쳤었어요. 보안 팀에서 로그 분석하다가 발견해서 "이거 누가 한 거냐"고 추궁당했습니다. 부끄러웠어요.

가급적:

• 파일: 644 (주인만 쓰기)
• 실행 파일: 755 (주인만 쓰기, 나머지는 실행 가능)
• 민감한 파일 (SSH 키, 비밀번호 파일): 600 (주인만 읽기/쓰기)

이 정도로 막아두는 게 국룰입니다.

내가 받아들인 핵심 개념

1. rwx는 3비트 플래그다. r=4, w=2, x=1. 더하면 0~7까지 나온다.
2. Owner / Group / Others 3계층으로 관리한다. 아파트 건물 비유가 딱이다.
3. 폴더의 x 권한은 "진입 권한"이다. 없으면 cd가 안 된다.
4. chmod는 권한 변경, chown은 주인 변경이다. 출입증 vs 명의 변경.
5. 777은 재앙의 시작이다. 편하다고 쓰면 나중에 후회한다.

이 개념들이 정리되고 나니, Permission denied 에러가 나면 "아, 이 파일 권한 확인해봐야겠다" 또는 "컨테이너 UID 맞는지 확인해야겠다"로 바로 대응할 수 있게 됐습니다.

---