각 부류 안의 세 자리는 r → w → x 순서로 고정이다. 권한이 있으면 글자, 없으면 -.
파일과 디렉터리에서 같은 글자라도 의미가 다르다. 파일에서 r=내용 읽기, w=내용 수정, x=실행. 디렉터리에서 r=목록 보기(ls), w=파일 생성/삭제, x=그 디렉터리 안으로 진입(cd)이다. 특히 디렉터리의 x가 없으면 r이 있어도 그 안의 파일에 접근할 수 없다(이름은 보여도 들어갈 수 없음). 시험에서 "디렉터리에 x만 있고 r이 없으면?" → 이름은 못 보지만 정확한 파일명을 알면 접근 가능, 같은 함정으로 출제된다.
디렉터리에서 파일을 삭제하려면 그 파일에 대한 쓰기 권한이 아니라 디렉터리에 대한 w 권한이 필요하다. 파일 자체가 읽기 전용(444)이어도 그 파일이 든 디렉터리에 w가 있으면 삭제된다. 이것이 직관에 어긋나 헷갈리기 쉽다. (Sticky bit가 이 동작을 제한하는데, Day 4에서 다룬다.)
각 권한에는 가중치가 있다: r=4, w=2, x=1. 한 부류의 권한을 더하면 0~7의 숫자가 나온다.
rwx
계산
8진수
---
0
0
--x
1
1
-w-
2
2
-wx
2+1
3
r--
4
4
r-x
4+1
5
rw-
4+2
6
rwx
4+2+1
7
세 부류를 각각 계산해 이어 붙이면 세 자리 8진수가 된다.
rwxr-xr--
rwx = 7, r-x = 5, r-- = 4 → 754
r=4, w=2, x=1은 2진수 비트 가중치(2², 2¹, 2⁰)다. rwx 세 비트를 2진수로 보면 111=7, 101=5, 100=4가 된다. 그래서 8진수 한 자리(0~7)가 세 비트를 정확히 표현한다. 이 대응을 알면 변환이 암기가 아니라 계산이 된다.
자주 쓰는 권한 숫자는 통째로 외워두면 빠르다.
8진수
rwx
용도
644
rw-r--r--
일반 파일 기본(소유자 읽기/쓰기, 나머지 읽기)
755
rwxr-xr-x
실행 파일·디렉터리 기본
600
rw-------
개인 비밀 파일(SSH 키 등)
700
rwx------
개인 디렉터리
777
rwxrwxrwx
모두 전체 권한(보안상 지양)
400
r--------
읽기 전용 비밀 파일
⚠️ 함정: 644를 "소유자만 쓸 수 있고 나머지는 읽기"로 정확히 풀어야 한다. 6=rw-(소유자), 4=r--(그룹), 4=r--(기타). 이걸 "모두 읽기/쓰기"로 착각하거나 755(rwxr-xr-x)와 헷갈리는 보기가 오답으로 쓰인다. 또 chmod 숫자를 거꾸로(other부터) 읽는 실수도 흔하다 — 항상 owner-group-other 순이다.
8진수 방식은 전체를 덮어쓰기, 기호 방식은 부분만 변경이다. 기존 권한을 모르거나 깡그리 새로 정할 땐 8진수가, "실행 권한만 살짝 추가"처럼 일부만 바꿀 땐 기호 방식이 적합하다. chmod +x처럼 대상을 생략하면 umask의 영향을 받아 a(전체)에 적용되되 umask가 막는 비트는 빠진다.
chmod -R(재귀)을 파일과 디렉터리에 일괄 적용할 때 함정이 있다. 디렉터리는 진입을 위해 x가 필요하지만 일반 파일에는 x가 불필요(보안 위험)하다. chmod -R 755를 통째로 걸면 모든 파일에도 실행 권한이 붙는다. 이를 피하려면 find /path -type d -exec chmod 755 {} \;와 find /path -type f -exec chmod 644 {} \;로 종류별로 나누거나, 기호 방식의 대문자 X(chmod -R a+X)를 쓴다. 대문자 X는 "디렉터리이거나 이미 누군가에게 x가 있는 파일"에만 x를 추가한다.
⚠️ 함정: chmod 777은 "문제를 빠르게 해결"하는 만능키처럼 보이지만, 누구나 쓰기·실행이 가능해져 심각한 보안 구멍이다. 웹 서버 디렉터리에 777을 거는 것은 공격자가 악성 스크립트를 심을 길을 열어준다. 시험에서 "권한 문제 해결책으로 777" 보기는 오답이다.
# 직접 쳐보기 — 권한 변환 연습touch demo.txt && ls -l demo.txt # 기본 권한 확인chmod 640 demo.txt && ls -l demo.txt # rw-r----- 확인chmod u+x,o-r demo.txt && ls -l demo.txt # 기호 방식 변화 관찰stat -c "%a %A %n" demo.txt # 8진수와 rwx를 동시에
chown alice file.txt # 소유자를 alice로chown alice:dev file.txt # 소유자 alice, 그룹 dev로 동시 변경chown :dev file.txt # 그룹만 dev로(콜론 앞 생략)chown -R alice:dev /var/www # 하위 전체 재귀chgrp dev file.txt # 그룹만 변경(chown :dev와 동일)
chown user:group 형식에서 콜론 앞은 소유자, 뒤는 그룹이다. 콜론 앞을 생략(chown :group)하면 그룹만 바뀌어 chgrp group과 같다. 소유자만 바꾸려면 콜론을 빼고 chown user로 한다.
chown(소유자 변경)은 root만 할 수 있다. 일반 사용자는 자기 파일이라도 다른 사람에게 소유권을 넘길 수 없다(권한을 넘기면 디스크 쿼터 회피 등 악용 가능). 다만 자기가 속한 그룹으로의 chgrp는 일반 사용자도 가능하다. "일반 사용자가 chown으로 소유자 변경 가능?" → 불가능이 정답이다.
웹 배포 후 "Permission denied"가 뜨는 전형적 원인은 파일 소유자가 배포한 사람(예: deploy)인데 웹 서버는 www-data/apache 사용자로 동작하기 때문이다. 해결은 chown -R www-data:www-data /var/www로 소유권을 웹 서버 사용자에게 넘기는 것. 이때 777로 권한을 열어 우회하는 건 보안상 최악수다 — 소유권을 맞추는 것이 정답이고 권한을 푸는 것은 오답이라는 패턴으로 출제된다.
파일이 666에서 시작하는 이유는, 새로 만든 파일에 실행 권한(x)을 자동으로 주면 위험하기 때문이다(스크립트가 의도치 않게 실행될 수 있음). 그래서 파일의 출발점은 x가 빠진 666이고, 디렉터리는 진입에 x가 필수라 777에서 출발한다. 같은 umask라도 파일과 디렉터리의 결과가 다른 건 이 출발점 차이 때문이다.
umask 계산은 엄밀히는 "뺄셈"이 아니라 비트 AND NOT(보수 마스킹)이다. umask의 각 비트가 1이면 그 권한을 끈다. 022를 2진수로 보면 000 010 010이고, 이 비트가 켜진 자리(group의 w, other의 w)를 666에서 끄면 644가 된다. 대부분의 경우 단순 뺄셈으로 같은 답이 나오지만, umask에 홀수(예: 027의 7)가 섞이면 뺄셈 직관이 어긋날 수 있어 비트 마스킹으로 이해하는 게 안전하다. 예: umask 027 → 파일 666 & ~027 = 640, 디렉터리 777 & ~027 = 750.
"umask 022면 새 파일이 755가 된다"는 틀렸다. 755는 디렉터리의 결과고, 파일은 666-022=644다. 파일과 디렉터리의 출발점(666 vs 777)을 혼동시키는 것이 umask 문제의 핵심 함정이다. 또 umask 값이 클수록 권한이 더 많이 깎여 더 제한적이 된다(077이 022보다 빡빡함).
# 직접 쳐보기 — umask 효과 관찰umask # 현재 umask(보통 0022)umask 077 # 더 제한적으로 변경touch secret.txt && ls -l secret.txt # 600 확인(666-077)mkdir secretdir && ls -ld secretdir # 700 확인(777-077)umask 022 # 원복
한 공유 서버에서 사용자들의 umask가 002로 설정돼 있어 새로 만드는 모든 파일이 664(그룹 쓰기 허용)였다. 같은 그룹원끼리 협업하는 환경에선 편리했지만, 한 사용자가 민감한 키 파일을 만들자 같은 그룹의 다른 사용자가 수정할 수 있는 상태가 됐다. 보안팀은 개인 작업용 계정의 기본 umask를 077로 강화하도록 /etc/profile과 ~/.bashrc를 조정했다. 시스템 전역 umask는 /etc/profile이나 /etc/login.defs에서, 개인은 ~/.bashrc에서 설정한다.