chmod 755와 644는 무슨 뜻일까: 권한 숫자와 rwx, 디렉터리의 x

chmod 755의 7과 5는 읽기·쓰기·실행 비트를 더한 8진수입니다. POSIX 규격을 기준으로 숫자와 rwx의 대응, 소유자·그룹·기타 판정, 디렉터리에서 r·w·x의 뜻, umask와 chmod -R의 함정을 정리했습니다.

개발운영체제리눅스

chmod 755 deploy.sh, chmod 644 index.html처럼 파일 권한은 흔히 숫자로 지정합니다. 이 세 자리 숫자는 권한 비트 9개를 8진수로 적은 값입니다. 아래에서 ‘규격’은 POSIX.1-2024(IEEE Std 1003.1-2024)를 가리키고, GNU나 Linux 문서에만 있는 내용은 따로 밝혔습니다. 실행 예는 Debian 13.7 컨테이너에서 GNU coreutils 9.7의 chmod를 일반 사용자 계정으로 실행한 결과입니다.

숫자 한 자리는 비트 세 개

규격의 chmod 대응표에서 소유자의 읽기·쓰기·실행은 0400·0200·0100, 그룹은 0040·0020·0010, 기타 사용자는 0004·0002·0001입니다. 한 자리 안에서 읽기 4, 쓰기 2, 실행 1이고, 켜진 비트의 값을 더한 것이 그 자리의 숫자입니다.

숫자 비트 ls -l 표기
7 4+2+1 rwx
6 4+2 rw-
5 4+1 r-x
4 4 r--
0 없음 ---

755는 소유자 7, 그룹 5, 기타 5이므로 rwxr-xr-x이고, 644는 rw-r--r--입니다. 755를 2진수로 쓰면 111 101 101입니다. 세 자리씩 끊으면 그대로 rwx 칸에 대응합니다. 8진수와 2진수 사이의 변환은 진법 변환기로 확인할 수 있습니다.

ls -l 맨 앞 문자열의 첫 글자는 파일 종류입니다. -는 일반 파일, d는 디렉터리, l은 심볼릭 링크를 뜻합니다. 그 뒤로 세 글자씩 소유자·그룹·기타의 권한이 옵니다. 권한 비트 외에 추가하거나 대체하는 접근 제어 수단이 있는 파일이면 끝에 한 글자가 더 붙을 수 있습니다.

숫자로 지정하면 기존 권한에 더하는 것이 아니라 통째로 바꿉니다. 숫자에 켜진 비트는 설정되고 나머지 권한 비트는 지워집니다. 실행 권한이 있던 파일에 chmod 644를 하면 실행 비트가 사라집니다.

세 칸 중 한 칸만 본다

어느 칸이 적용될지는 프로세스의 사용자 ID와 그룹 ID로 정해집니다.

  • 프로세스의 실효 사용자 ID가 파일의 소유자와 같으면 소유자 클래스입니다.
  • 소유자 클래스가 아니고, 실효 그룹 ID나 보조 그룹 ID 중 하나가 파일의 그룹과 같으면 그룹 클래스입니다.
  • 둘 다 아니면 기타 클래스입니다.

이 순서대로 클래스 하나만 고르고, 그 클래스의 비트만 봅니다. 소유자 칸이 비어 있으면 그룹이나 기타 칸에 읽기 권한이 있어도 소유자는 파일을 읽지 못합니다.

$ echo hi > f
$ chmod 044 f
$ ls -l f
----r--r-- 1 u u 3 Oct  2 02:04 f
$ cat f
cat: f: Permission denied

사용자 u는 파일의 그룹 u에도 속하지만 소유자 클래스로 판정되므로 그룹 칸의 r은 쓰이지 않습니다.

특권이 있는 프로세스는 다릅니다. 규격상 적절한 특권이 있으면 읽기·쓰기·디렉터리 검색은 허용되고, 실행은 세 실행 비트 중 하나라도 켜져 있을 때 허용됩니다. Linux의 path_resolution(7)에 따르면 Linux는 이 특권을 capability로 나눕니다. CAP_DAC_OVERRIDE는 권한 검사를 건너뛰지만, 실행 권한은 실행 비트가 하나 이상 켜져 있을 때만 줍니다. root로는 위 예의 읽기가 거부되지 않으므로 권한 실험은 일반 사용자로 해야 합니다.

디렉터리에서 r, w, x의 뜻

같은 비트라도 디렉터리에서는 뜻이 달라집니다. GNU coreutils 문서에서 디렉터리의 읽기는 내용 목록 보기, 쓰기는 파일 만들기와 지우기, 실행은 디렉터리 안의 파일에 접근하기를 뜻합니다. 규격은 디렉터리의 x를 검색(search) 권한이라고 부릅니다. path_resolution(7)에 따르면 경로를 따라갈 때 거치는 디렉터리마다 검색 권한이 필요하며, 없으면 EACCES 오류가 납니다.

따라서 r과 x는 따로 작동합니다.

$ mkdir box && echo hi > box/a.txt
$ chmod 600 box          # rw-: 목록은 읽지만 검색은 못 함
$ ls box
a.txt
$ cat box/a.txt
cat: box/a.txt: Permission denied

$ chmod 300 box          # -wx: 검색은 되지만 목록은 못 읽음
$ ls box
ls: cannot open directory 'box': Permission denied
$ cat box/a.txt
hi

r만 있으면 이름은 보여도 안의 파일을 열 수 없습니다. x만 있으면 목록은 볼 수 없지만 이름을 아는 항목은 찾아갈 수 있습니다. 실제로 열 수 있는지는 파일 자체의 권한과 다른 접근 제어에도 달려 있습니다. 목록을 보고 안의 파일에 접근하려면 r과 x가 모두 필요합니다.

같은 600·300 예를 macOS 15.6.1에서도 실행했습니다. cat의 허용·거부 결과는 같았습니다. 다만 600일 때 ls는 a.txt와 함께 ls: fts_read: Permission denied를 출력했고, 300일 때의 오류 문구도 달랐습니다.

파일을 지울 수 있는지는 디렉터리가 정한다

파일 삭제에 쓰이는 unlink()는 디렉터리 항목, 즉 파일의 이름을 지우는 동작입니다. 이 부분은 파일을 지웠는데 디스크 공간이 그대로인 이유에서도 다뤘습니다.

규격이 unlink()의 EACCES 조건으로 드는 것은 경로상 디렉터리의 검색 권한과, 지울 항목이 들어 있는 디렉터리의 쓰기 권한입니다. 파일 자신의 쓰기 비트는 이 조건에 없습니다. 파일이 읽기 전용이라는 사실만으로는 삭제가 막히지 않습니다.

여러 사용자가 함께 쓰는 디렉터리에서는 S_ISVTX 비트가 삭제를 제한합니다. 쓰기 가능한 디렉터리에 이 비트가 켜져 있으면 파일 소유자, 디렉터리 소유자, 적절한 특권이 있는 프로세스만 그 안의 파일을 지우거나 이름을 바꿀 수 있습니다. 파일에 쓰기 권한만 있는 프로세스까지 허용할지는 구현이 정합니다.

GNU chmod 문서는 이 비트를 restricted deletion flag 또는 sticky bit라고 부르며, /tmp처럼 누구나 쓸 수 있는 디렉터리에서 흔히 사용된다고 설명합니다. ls -l에서는 기타 칸의 마지막 글자가 t 또는 T로 표시됩니다. t는 기타 사용자에게 검색 권한이 있는 경우, T는 없는 경우입니다.

숫자 모드의 앞자리

규격의 대응표에는 앞자리도 있습니다. 4000은 set-user-ID, 2000은 set-group-ID, 1000은 S_ISVTX입니다. GNU chmod의 일반 숫자 모드는 1~4자리이고, 생략된 자리는 앞쪽의 0으로 봅니다. 따라서 755는 0755와 같습니다.

이 자리를 다루는 방식에는 구현 차이가 있습니다. 규격은 일반 파일이면 숫자에 없는 set-user-ID와 set-group-ID 비트를 지우도록 하지만, 그 밖의 파일 종류는 구현에 맡깁니다.

GNU chmod는 디렉터리의 두 set-ID 비트를 명시하지 않으면 그대로 둡니다. 숫자 모드로 지우려면 예외적으로 앞에 0을 하나 더 붙여 00755처럼 씁니다. 실제로 g+s를 켠 디렉터리에 chmod 755를 하자 모드는 2755로 남았고, chmod 00755를 한 뒤에야 755가 되었습니다.

기호 모드와 umask

chmod u=rwx,go=rx는 rwx 아홉 비트를 755와 같게 맞춥니다. =은 지정한 칸을 그 값으로 맞추고, +와 -는 현재 권한에 더하거나 뺍니다.

u, g, o, a를 생략할 때는 주의해야 합니다. 이때 프로세스의 파일 모드 생성 마스크인 umask에서 켜진 비트는 변경되지 않습니다.

umask가 022인 셸에서 모드가 444인 파일에 chmod +w를 하면 644가 되었고, chmod a+w를 하면 666이 되었습니다. 규격의 chmod 설명도 같은 이유로 chmod a-w file과 chmod -- -w file의 차이를 예로 듭니다.

umask는 새 파일을 만들 때도 쓰입니다. 마스크에서 켜진 비트는 새 파일의 모드에서 지워집니다. touch는 모든 사용자에게 읽기·쓰기인 0666을 요청하고, mkdir 명령은 0777을 요청합니다. 따라서 umask가 022이면 각각 644와 755가 됩니다. 이번 실행에서도 같은 결과가 나왔습니다.

chmod -R 755와 대문자 X

-R은 디렉터리와 그 아래 모든 파일의 모드를 바꿉니다. 디렉터리에 맞춰 chmod -R 755를 하면 일반 파일에도 실행 비트가 켜집니다.

이럴 때 기호 모드의 대문자 X를 쓸 수 있습니다. X는 대상이 디렉터리이거나 현재 모드에 실행 비트가 하나라도 켜져 있을 때만 실행 또는 검색 비트로 다뤄집니다. 그 밖의 파일에서는 무시됩니다.

$ mkdir -p t/d && touch t/d/x.txt
$ chmod -R u=rwX,go=rX t
$ stat -c '%A %a %n' t t/d t/d/x.txt
drwxr-xr-x 755 t
drwxr-xr-x 755 t/d
-rw-r--r-- 644 t/d/x.txt

$ chmod -R 755 t
$ stat -c '%A %a %n' t/d/x.txt
-rwxr-xr-x 755 t/d/x.txt

위의 u=rwX,go=rX 모드에서는 실행 비트가 하나라도 있던 파일에 go=rX가 적용되므로 그룹과 기타에도 실행 비트가 켜집니다.

-R을 처리할 때 디렉터리의 모드를 안의 파일보다 먼저 바꾸는지 나중에 바꾸는지는 구현마다 다릅니다. 규격은 자기 자신도 들어갈 수 없게 계층 전체의 권한을 없애지 말라고 권합니다.

이 글의 범위

규격은 구현이 권한 비트 외에 추가하거나 대체하는 접근 제어 수단을 둘 수 있게 합니다. 추가 수단은 권한 비트가 허용한 범위를 더 좁히는 쪽으로만 작동해야 합니다. GNU 문서도 ACL을 파일 시스템별 속성으로 언급합니다.

이 글은 ACL 같은 추가 접근 제어, 네트워크 파일 시스템, Windows의 권한 모델을 다루지 않습니다. 그런 환경에서는 권한 비트만으로 결과를 판단할 수 없습니다.

참고한 명세와 문서

링크와 내용은 2026년 10월 2일에 확인했습니다.

블로그로