
chmod 777이 위험한 이유 — 리눅스 파일 권한 644·755·600 설정법
chmod 777은 권한 문제를 한 방에 없애주는 것 같지만, 실제로는 서버를 통째로 위험에 노출시킨다. 777이 위험한 진짜 이유와 권한 숫자 읽는 법, 644·755·600 같은 상황별 올바른 권한 설정까지 정리했다.
서버에서 뭔가 안 풀릴 때 chmod 777만큼 손이 빨리 나가는 명령도 없다. 퍼미션 에러 한 줄 뜨면 일단 777부터 때려 넣고 "어, 되네" 하고 넘어간 경험, 리눅스 좀 만져본 사람이라면 다들 한 번쯤 있을 거다.
솔직히 나도 그랬다. 급한 배포에서 업로드 폴더가 안 써진다길래 chmod -R 777로 디렉토리를 통째로 열어버리고 그날은 퇴근했다. 코드는 멀쩡히 돌아갔고, 문제는 해결된 것처럼 보였다. 진짜 문제는 그게 "해결"이 아니었다는 데 있다.

왜 다들 777부터 치게 되냐면
777이 매력적인 이유는 하나다. 권한 때문에 막히는 모든 경우의 수를 한 번에 없애준다. 읽기도 쓰기도 실행도 전부 열어버리니, 적어도 "Permission denied"는 다시 안 뜬다.
그런데 그건 문제를 푼 게 아니라 문제를 안 보이게 덮은 것에 가깝다. 퍼미션 에러는 거의 항상 진짜 원인을 가리키고 있다. 웹서버 프로세스가 그 폴더에 쓸 권한이 없거나, 스크립트에 실행 비트가 안 붙었거나, 파일 소유자가 엉뚱한 계정이거나. 777은 이 신호들을 한꺼번에 지워버린다. 그래서 나중에 진짜 사고가 터졌을 때 어디서부터 꼬였는지 되짚기가 훨씬 어려워진다.
더 고약한 건, 777이 "잘 돌아간다"는 착각을 준다는 점이다. 당장 에러가 안 나니까 그대로 운영에 올라가고, 몇 달 뒤 보안 점검에서 world-writable 파일이 수백 개 발견되는 식이다.
777이 정확히 무엇을 여는지
chmod 777 파일을 치는 순간 그 파일의 권한은 이렇게 바뀐다.
-rwxrwxrwx
rwx 세 글자가 세 번 반복된다. 각각 소유자(owner) / 그룹(group) / 나머지 전부(other)를 뜻한다. 여기서 진짜 위험한 건 맨 뒤, other에 붙은 w(쓰기)다.
그 서버에 계정이 있는 사람이면 누구든, 심지어 권한을 탈취당한 웹 프로세스까지, 그 파일을 마음대로 고쳐 쓸 수 있다는 의미다. 777의 핵심 위협은 "내가 실수로 지운다"가 아니라 "남이 내 파일을 바꾼다"에 있다.
여러 서비스가 한 서버에 올라간 환경이나 공유 호스팅이면 사정이 더 나쁘다. 옆 계정 하나가 털리면 내 777 파일이 그대로 침투 통로가 된다. 특히 웹 루트(document root)를 777로 열어두면, 공격자가 웹셸을 슬쩍 얹거나 index 파일을 바꿔치기하는 고전적인 변조 경로가 열린다. 실제로 사이트 변조 사고의 상당수가 "어쩌다 열어둔 world-writable 디렉토리"에서 시작한다.
777은 "편하게 열어둔 문"이 아니라 "잠그는 걸 깜빡한 금고"에 가깝다.

권한 숫자, 1분이면 읽는다
숫자가 암호처럼 보이지만 규칙은 허탈할 만큼 단순하다. 권한은 세 종류뿐이고 각자 값이 정해져 있다.
| 권한 | 기호 | 숫자 |
|---|---|---|
| 읽기 (read) | r | 4 |
| 쓰기 (write) | w | 2 |
| 실행 (execute) | x | 1 |
한 자리 숫자는 이 셋을 더한 값이다. 읽기+쓰기+실행이면 4+2+1=7, 읽기+실행이면 4+1=5, 읽기만이면 4. 그래서 0부터 7까지로 한 묶음의 권한이 표현된다.
| 숫자 | 기호 | 의미 |
|---|---|---|
| 7 | rwx | 읽기·쓰기·실행 전부 |
| 6 | rw- | 읽기·쓰기 |
| 5 | r-x | 읽기·실행 |
| 4 | r-- | 읽기만 |
| 0 | --- | 아무 권한 없음 |
그리고 숫자 세 자리는 각각 owner / group / other 순서다. 그러니 755를 풀어 쓰면 소유자는 rwx(7), 그룹은 r-x(5), 나머지는 r-x(5) — 소유자만 고칠 수 있고 나머지는 읽고 실행만 가능하다는 뜻이 된다. 777은 이 세 자리가 전부 7, 즉 모두에게 모든 걸 연 상태다.
상황별로 '정답'에 가까운 권한
외울 필요는 없고, 대부분은 아래 몇 개로 끝난다.
| 대상 | 권한 | 기호 | 이유 |
|---|---|---|---|
| 일반 파일 (HTML·이미지·설정) | 644 | rw-r--r-- | 소유자만 수정, 나머지는 읽기만 |
| 디렉토리 | 755 | rwxr-xr-x | 디렉토리는 x가 있어야 안으로 들어갈 수 있다 |
| 실행 스크립트 | 755 | rwxr-xr-x | 모두 실행 가능, 수정은 소유자만 |
민감 파일 (.env·개인키·DB설정) | 600 | rw------- | 소유자만 읽고 쓰기, 나머지는 접근 불가 |
| SSH 개인키 | 600 | rw------- | 느슨하면 ssh가 아예 키를 거부한다 |
여기서 자주 헷갈리는 포인트. 디렉토리의 x는 "실행"이 아니라 "그 안으로 진입(cd)할 수 있는 권한"이다. 그래서 디렉토리는 644가 아니라 755가 기본이다. 반대로 일반 파일에 실행 비트(x)를 굳이 줄 이유는 거의 없다.
웹 업로드 디렉토리는 특히 조심해야 한다. "쓰기가 돼야 하니까" 777을 주기 쉬운데, 쓰기 권한이 필요한 건 그 디렉토리를 돌리는 프로세스(예: www-data)지 세상 모든 계정이 아니다. 이건 권한을 넓혀서가 아니라 소유권으로 풀어야 하는 문제다.
권한을 넓히기 전에, 소유권부터 본다
777을 치고 싶어지는 상황의 십중팔구는 "쓰려는 프로세스와 파일 소유자가 안 맞아서"다. 이럴 땐 권한을 모두에게 여는 대신 소유자나 그룹을 맞춰주면 된다.
chown -R www-data:www-data /var/www/uploads
chmod -R 755 /var/www/uploads
이렇게 하면 웹서버 프로세스(www-data)는 제 폴더처럼 쓰고, 나머지 계정에는 읽기만 허용된다. 여러 사람이 같은 디렉토리를 함께 써야 한다면 공용 그룹을 만들어 chgrp로 묶고 그룹에만 쓰기(775)를 주는 방법도 있다. 요지는 하나다. 필요한 쪽에만 딱 그만큼 열어준다는 최소 권한 원칙.
그리고 하나 덧붙이자면, 국내 환경에선 이게 남 얘기가 아니다. 카페24·가비아 같은 공유 호스팅에서 "파일 업로드가 안 돼요" 질문에 커뮤니티가 습관처럼 "777 주세요"라고 답하는 걸 아직도 자주 본다. 공유 서버는 한 호스트에 수십 개 사이트가 같이 올라가 있는 구조라, world-writable 파일이 오히려 가장 위험한 환경이다. 개인 VPS든 공유 호스팅이든, "되게 하려고 777" 대신 "누가 이걸 써야 하지?"를 먼저 묻는 습관 하나가 사고의 절반을 막아준다. 실무에서 보안 점검 때 가장 먼저 걸러내는 항목이 바로 이 world-writable 파일 목록이기도 하다.
정리하면
777은 문제를 푸는 게 아니라 모두에게 모든 권한을 열어 문제를 가린다.- 숫자는 r=4·w=2·x=1을 더한 값이고, 세 자리는 owner·group·other 순서다.
- 일반 파일
644, 디렉토리·스크립트755, 민감 파일600이 세 개면 거의 다 된다. - 쓰기가 안 되면 권한을 여는 대신
chown으로 소유권을 맞춰라.
혹시 지금 운영 중인 서버에 chmod -R 777로 열어둔 폴더가 있다면, find / -perm -0002 -type f 한 줄로 world-writable 파일부터 찾아보길 권한다. 여러분은 777을 언제 마지막으로 쳤고, 그게 아직도 그 상태로 남아 있진 않은가?
댓글 0
댓글을 불러오는 중…