왜 권한이라는 개념이 필요한가

리눅스는 원래부터 여러 사람이 하나의 컴퓨터를 함께 쓰는 것을 전제로 설계되었다(다중 사용자 시스템, multi-user system). 학교 실습실의 리눅스 서버에 수십 명의 학생이 각자 계정으로 접속한다고 생각해 보자. 만약 아무런 제약이 없다면, 어떤 학생이 실수로(또는 고의로) 다른 학생의 과제 파일을 지우거나, 시스템 설정 파일(09편에서 다룬 /etc 아래 파일들)을 함부로 고쳐 서버 전체를 망가뜨릴 수 있다.

이 문제를 막기 위해 리눅스는 모든 파일과 디렉터리에 “누가 무엇을 할 수 있는가”를 표시하는 권한(permission) 정보를 붙여 둔다. ls -l 명령으로 파일 목록을 보면 맨 앞에 나오는 문자열이 바로 이 권한 정보다.

$ ls -l report.txt
-rwxr-xr-- 1 ihduser project 4096 Sep  1 10:00 report.txt

쉽게 말하면: 권한은 “이 파일에 대해 누구는 읽기만, 누구는 읽고 쓰기까지, 누구는 아예 접근 불가”를 정해 두는 출입증 시스템이다.

소유자·그룹·기타의 3자 구조

리눅스는 파일에 접근하려는 사람을 딱 세 부류로만 나눈다. 이 셋을 넘어서는 세분화(예: “이 사람에게만 읽기 허용”)는 기본 권한 체계로는 할 수 없다(더 세밀한 제어가 필요하면 ACL이라는 별도 기능을 쓰지만, 이는 2급 1차 범위를 넘어선다).

ls -l의 출력에서 -rwxr-xr-- 문자열은 이 세 부류에 각각 3칸씩, 총 9칸으로 나뉜다. 맨 앞의 한 글자는 파일 종류를 나타내는 별도 칸이다(-는 일반 파일, d는 디렉터리, l은 심볼릭 링크).

각 3칸 안에서 순서는 항상 고정이다. 첫 칸이 r(read, 읽기), 둘째 칸이 w(write, 쓰기), 셋째 칸이 x(execute, 실행)다. 권한이 없으면 그 자리에 -가 온다.

기호 표기와 8진수 표기 — 자리별로 완전히 펼쳐 보기

리눅스 명령어에서 권한을 다룰 때는 rwxr-xr--처럼 문자로 쓰는 기호 표기(symbolic notation)와, 754처럼 숫자 세 자리로 쓰는 8진수 표기(octal notation) 두 가지를 함께 쓴다. 이 둘을 자유롭게 오가는 것이 이 단원에서 가장 중요한 계산 능력이다.

쉽게 말하면: 기호 표기는 “읽기 있음, 쓰기 있음, 실행 없음”을 글자로 나열한 것이고, 8진수 표기는 같은 정보를 숫자 하나로 압축한 것이다.

왜 하필 8진수인가

각 칸(r, w, x)은 “있다/없다” 두 가지 상태만 가지는 하나의 스위치, 즉 1비트(bit)다. 한 부류(소유자·그룹·기타)당 스위치가 3개씩 있으므로, 한 부류의 상태는 3비트로 표현된다. 3비트로 표현할 수 있는 값의 범위는 2진수로 000부터 111까지, 즉 10진수로 0부터 7까지다. 그리고 이 3비트를 그대로 10진수처럼 다루면 8진수(0~7) 표기가 된다. 그래서 리눅스 권한은 “0부터 7까지의 숫자 하나가 정확히 3개의 온/오프 스위치 상태를 표현하는” 8진수 체계를 쓴다.

각 자리의 값은 다음 공식으로 계산한다.

• $r$, $w$, $x$는 각각 그 권한이 있으면 1, 없으면 0이다.
• $r$의 자리값이 4, $w$의 자리값이 2, $x$의 자리값이 1인 이유는 2진수 100(4) · 010(2) · 001(1)에서 그대로 온 것이다 — 세 스위치가 동시에 켜지는 경우가 없도록(자릿수가 겹치지 않도록) 이진법의 자리값을 그대로 쓴 것이다.

기호 → 8진수: rwxr-xr--를 자리별로 전부 펼치기

rwxr-xr--를 8진수로 바꾸는 과정을 소유자·그룹·기타 세 구간으로 나누어, 한 글자도 건너뛰지 않고 전부 펼쳐 본다.

1단계 — 소유자(owner) 구간: rwx

2단계 — 그룹(group) 구간: r-x

3단계 — 기타(other) 구간: r--

4단계 — 세 구간을 순서대로 이어 붙인다.

즉 rwxr-xr--는 8진수 754다.

8진수 → 기호: 반대 방향으로 검산하기

방금 얻은 754가 맞는지 확인하려면, 거꾸로 754를 다시 기호 표기로 되돌려서 원래 문자열과 일치하는지 봐야 한다.

1단계 — 각 자리 숫자를 4, 2, 1로 다시 쪼갠다.

2단계 — 있음(1)/없음(0)을 다시 r, w, x 글자로 바꾼다.

• 소유자: r 있음, w 있음, x 있음 → rwx
• 그룹: r 있음, w 없음, x 있음 → r-x
• 기타: r 있음, w 없음, x 없음 → r--

3단계 — 이어 붙인다.

원래 문자열 rwxr-xr--와 정확히 일치한다. 검산 완료.

연습 하나 더 — 8진수 640을 기호로

이번에는 8진수에서 시작해 보자. 640을 자리별로 4·2·1로 쪼갠다.

• 소유자 자리 6 = 4(r) + 2(w) + 0(x 없음) → rw-
• 그룹 자리 4 = 4(r) + 0(w 없음) + 0(x 없음) → r--
• 기타 자리 0 = 권한 전혀 없음 → ---

이어 붙이면 rw-r-----이다. 역방향 검산: rw-r-----을 다시 8진수로 바꾸면 소유자 rw-=4+2=6, 그룹 r--=4, 기타 ---=0이므로 640이 그대로 나온다. 일치한다.

chmod·chown·chgrp — 권한과 소유권을 바꾸는 명령

chmod — 권한 변경

chmod(change mode)는 권한을 바꾸는 명령이며, 8진수 방식과 기호 방식 두 가지로 쓸 수 있다.

# 8진수 방식 — 전체 권한을 한 번에 지정
chmod 754 report.txt
 
# 기호 방식 — 특정 부류의 특정 권한만 추가·제거
chmod u+x report.txt      # 소유자(u)에게 실행 권한 추가
chmod g-w report.txt      # 그룹(g)에서 쓰기 권한 제거
chmod o=r report.txt      # 기타(o)의 권한을 읽기 전용으로 지정(=은 있는 그대로 대입)
chmod a+r report.txt      # 모두(a, all)에게 읽기 권한 추가

기호 방식에서 대상 지정 문자는 u(user, 소유자), g(group, 그룹), o(other, 기타), a(all, 전체) 네 가지이고, 연산자는 +(추가), -(제거), =(지정한 값으로 대체) 세 가지다.

디렉터리와 그 안의 모든 파일·하위 디렉터리에 한꺼번에 권한을 적용하려면 -R(recursive, 재귀적) 옵션을 쓴다.

chmod -R 755 data

reference 기출에서 -r(소문자)과 -R(대문자)을 헷갈리게 하는 오답이 등장한다. chmod에서 재귀 옵션은 **반드시 대문자 -R**이다. 소문자 -r은 chmod에 존재하지 않는 옵션이다.

chown·chgrp — 소유권 변경

chown(change owner)은 소유자를, 필요하면 그룹까지 동시에 바꾼다. chgrp(change group)는 그룹만 바꾼다.

# 소유자만 변경
chown ihduser report.txt
 
# 소유자와 그룹을 동시에 변경 (콜론으로 구분, 소유자가 앞)
chown ihduser:kait report.txt
 
# 그룹만 변경
chgrp kait report.txt

chown 소유자:그룹 형식에서 콜론 앞이 소유자, 뒤가 그룹이라는 순서를 정확히 기억해야 한다. reference 기출에서 “그룹 소유권을 kait, 소유자는 ihduser로 설정하라”는 지문에 대해 chown ihduser:kait와 chown kait:ihduser를 헷갈리게 하는 선택지가 나온다. 지문을 다시 우리말로 옮기면 “소유자는 ihduser, 그룹은 kait”이므로 정답은 chown ihduser:kait이고, 순서를 뒤집은 chown kait:ihduser는 그룹과 소유자가 뒤바뀐 오답이다. 또한 존재하지 않는 명령어 charp를 chown이나 chgrp인 것처럼 섞어 놓는 오답 패턴도 반복되므로, 명령어 철자 자체를 정확히 기억해야 한다.

umask 계산 — 왜 뺄셈처럼 보이는가

새 파일이나 디렉터리를 만들 때, 매번 chmod로 권한을 일일이 지정하지 않아도 시스템이 기본 권한을 자동으로 부여한다. 이 기본 권한을 결정하는 값이 umask(user mask, 사용자 마스크)다.

쉽게 말하면: umask는 “새로 만드는 파일·디렉터리에 자동으로 빼놓을 권한 비트를 미리 정해 두는 값”이다.

파일과 디렉터리의 기본값이 왜 다른가

umask를 적용하기 전, 리눅스가 정해 둔 최대 기본값(umask 0000일 때 부여될 값)은 파일과 디렉터리가 서로 다르다.

umask가 실제로 하는 일: “빼기”가 아니라 “끄기”

umask 값 자체도 권한과 똑같이 8진수 세 자리로 표기한다. 예를 들어 umask가 022라면, 이 022에서 1로 켜진 비트에 해당하는 권한을, 기본값에서 강제로 꺼 버린다.

이 동작의 정확한 이름은 비트 AND 연산(정확히는 “기본값 AND NOT(umask)“)이다. umask 값에서 1인 비트 자리는 기본값에서도 그 자리를 0으로 만들고, umask 값에서 0인 비트 자리는 기본값을 그대로 둔다.

왜 뺄셈처럼 보이는가: 겉보기에는 “666에서 022를 뺀 644”처럼 마치 자릿수별 뺄셈을 한 것처럼 보인다. 하지만 실제 연산은 뺄셈이 아니라 비트를 하나씩 끄는 것이다. 우연히 두 방식의 결과가 같아 보이는 이유는, umask로 끄려는 비트가 항상 “기본값에서 이미 켜져 있던 비트”이기 때문이다. 이미 켜진 비트 하나를 끄는 것은 자리값을 그대로 빼는 것과 결과가 같다(예: 켜져 있던 w(2)를 끄면 6에서 2를 뺀 4와 정확히 일치). 다만 이는 자릿내림(borrow)이 필요 없는 특수한 상황이라 뺄셈처럼 “보이는” 것일 뿐, 원리는 어디까지나 “기본값에서 umask가 지정한 비트를 하나씩 끈다”는 것이다.

계산 예시 1 — umask 022

파일 (기본값 666)

디렉터리 (기본값 777)

검산: 결과 rw-r--r--(파일)을 다시 8진수로 환산하면 소유자 6, 그룹 4, 기타 4 → 644로 원래 계산과 일치한다. 디렉터리 rwxr-xr-x도 소유자 7, 그룹 5, 기타 5 → 755로 일치한다.

계산 예시 2 — umask 0027 (reference 모의고사 실제 출제 방식)

reference 자료(모의고사 659번)에는 “현재 umask 값이 0027인 상태에서 사용자가 새 디렉터리를 생성하였다. 생성된 디렉터리의 권한을 8진수로 나타내면?”이라는 형태의 문제가 등장한다. 같은 방식으로 풀어 본다.

디렉터리 (기본값 777, umask 027)

검산: rwxr-x---을 다시 8진수로 바꾸면 소유자 rwx=7, 그룹 r-x=5, 기타 ---=0 → 750으로 일치한다.

특수 권한: SetUID·SetGID·스티키 비트

지금까지 다룬 9개 비트(소유자·그룹·기타 각 3개)만으로는 표현할 수 없는 세 가지 특별한 동작이 있다. 이를 위해 8진수 표기 맨 앞에 네 번째 자리를 추가로 쓴다.

쉽게 말하면: 특수 권한은 “이 파일을 실행하는 동안 잠깐 다른 사람인 척하게 해 주는” 또는 “이 디렉터리 안에서는 남의 파일을 함부로 못 지우게 막는” 특별 스위치다.

8진수 앞자리와 기호의 대응

세 값을 합산해 8진수 네 자리로 쓸 수도 있다. 예를 들어 SetUID와 일반 권한 755를 함께 주려면 4755처럼 앞자리에 4를 붙인다.

# SetUID 부여
chmod 4755 program
chmod u+s program
 
# SetGID 부여 (디렉터리에 걸어 그룹 상속시키는 경우가 흔하다)
chmod 2775 /project
chmod g+s /project
 
# 스티키 비트 부여 (공유 디렉터리에 흔히 사용, /tmp가 대표적 예)
chmod 1777 /tmp
chmod o+t /tmp

실전 예시로 검산하기 — /usr/bin/passwd

reference 모의고사(659번)에 등장한 예시를 그대로 계산해 검산해 본다.

-rwsr-xr-x. 1 root root 35000 Jun  1 10:00 /usr/bin/passwd

기호 → 8진수 변환

검산(역방향): 4755를 다시 풀면, 앞자리 4는 SetUID, 나머지 755는 rwxr-xr-x인데 SetUID가 소유자의 실행(x) 자리를 s로 바꾸므로 최종 기호는 rwsr-xr-x가 된다. 원래 ls -l 출력과 정확히 일치한다.

이 파일이 왜 SetUID를 갖는지도 함께 이해해야 한다. passwd 명령은 /etc/shadow(사용자 비밀번호가 암호화되어 저장된 파일 — 12편)를 수정해야 하는데, 이 파일은 root만 쓸 수 있다. 만약 SetUID가 없다면 일반 사용자는 자기 비밀번호조차 바꿀 수 없다. SetUID 덕분에 일반 사용자가 passwd를 실행하는 순간만큼은 root 권한을 빌려 /etc/shadow를 수정할 수 있게 된다.

대문자 S·T와 소문자 s·t의 차이

특수 권한 기호가 표시되는 자리는 원래 실행(x) 권한이 표시되던 자리와 같다. 그래서 그 자리에 실행 권한이 원래 있었는지 없었는지에 따라 대문자와 소문자가 갈린다.

예를 들어 어떤 파일의 소유자 실행 권한이 애초에 꺼져 있는데(rw-) 거기에 SetUID를 걸면 rwS로 표시된다. 대문자 S는 “SetUID는 켜져 있지만, 정작 실행 권한이 없어 이 SetUID가 실질적인 효과를 내지 못한다”는 경고에 가깝다. reference 기출에서 “소유자에게 실행 권한(x)이 없다면 s 대신 대문자 S로 표시된다”는 서술이 옳은 설명으로 등장하는데, 정확히 이 규칙을 가리킨다.

왜 디렉터리에서는 x가 “실행”이 아니라 “진입”을 뜻하는가

일반 파일에서 x는 그 파일을 프로그램으로 실행할 수 있는지를 의미했다. 그런데 디렉터리는 애초에 “실행”할 수 있는 대상이 아니다(디렉터리 자체를 프로그램처럼 구동시킬 수는 없다). 그런데도 왜 디렉터리에 x 비트가 존재할까.

그 답은 디렉터리의 내부 구조에 있다. 디렉터리는 사실 “그 안에 어떤 파일 이름이 있고, 그 이름이 어떤 inode 번호(파일의 실제 위치와 메타데이터를 가리키는 고유 번호 — 09·10편에서 다룬 개념)와 연결되어 있는가”를 기록해 둔 특수한 종류의 파일이다.

• r(읽기) 권한은 이 디렉터리 안에 “어떤 이름들이 들어 있는지” 목록을 볼 수 있게 해 준다(ls로 파일 이름들이 보인다).
• x(실행) 권한은 이 디렉터리 안으로 들어가서(cd), 그 안의 특정 이름 하나를 실제로 찾아 접근할 수 있게 해 준다. 정확히는, 어떤 경로(path)든 그 경로에 포함된 각 디렉터리를 하나씩 거쳐 갈 때마다 그 디렉터리에 대한 x 권한이 있어야, 커널이 “이 이름이 가리키는 파일이 어디 있는지”를 알아낼 수 있다.

이 둘은 완전히 독립적으로 작동한다. 만약 어떤 디렉터리에 r은 있지만 x가 없다면(r-------- 같은 상태), ls로 파일 이름 목록은 볼 수 있어도, 그 이름으로 실제 파일을 열거나 그 디렉터리 안으로 cd할 수는 없다 — 이름은 보이는데 그 이름이 가리키는 실체에는 접근할 수 없는 상태다. 반대로 x만 있고 r이 없다면(--x------), 안에 어떤 파일이 있는지 목록은 볼 수 없지만, 이름을 이미 정확히 알고 있는 파일이라면 그 파일에는 접근할 수 있다.

쉽게 말하면: 디렉터리의 r은 “방 안에 있는 물건 목록표를 볼 수 있는 권한”이고, x는 “그 방문을 실제로 열고 들어갈 수 있는 권한”이다. 목록표만 봤다고 방에 들어갈 수 있는 건 아니고, 문을 열 수 있다고 목록표가 저절로 보이는 것도 아니다.

그래서 디렉터리의 기본 최대 권한이 파일과 달리 777인 이유도 다시 확인할 수 있다 — 디렉터리는 x(진입) 없이는 애초에 그 존재 목적을 다하지 못하는 자원이기 때문에, 파일처럼 x를 기본에서 빼 두지 않는다.

직접 해보기 1 — 권한 표기 변환

파일을 하나 만들어 chmod 754를 걸고, ls -l로 정말 rwxr-xr--가 나오는지 확인한다. 이어서 기호 표기로 바꿔 보고 8진수가 어떻게 변하는지 stat으로 확인한다.

touch perm.txt
chmod 754 perm.txt
ls -l perm.txt
chmod u+x,g-w perm.txt
stat -c '%a %A' perm.txt

stat -c '%a %A'는 그 파일의 권한을 8진수(%a)와 기호 표기(%A)로 나란히 보여 주는 옵션이다.

무엇을 보아야 하나: 첫 ls -l의 앞 10칸이 본문에서 계산한 rwxr-xr--와 일치하는지 본다. u+x(이미 있던 소유자 실행 권한이라 변화 없음)와 g-w(그룹 쓰기 제거)를 적용한 뒤 stat이 출력하는 8진수가 754에서 어떻게 바뀌었는지 확인한다.

왜 이걸 해보나: 기호 표기와 8진수를 서로 변환하는 계산이 시험에서 가장 자주 나오는 문항 유형이다. 직접 명령으로 걸어 보고 눈으로 확인해야 자릿값 계산이 몸에 남는다.

직접 해보기 2 — umask

umask는 왜 뺄셈처럼 “보이는지”를 직접 몸으로 확인한다. 파일과 디렉터리를 만들어 권한을 비교하고, umask를 바꿔 다시 비교한다.

umask
touch f1.txt && mkdir d1
ls -ld f1.txt d1
umask 077
touch f2.txt && mkdir d2
ls -ld f2.txt d2

무엇을 보아야 하나: 첫 ls -ld에서 f1.txt(파일, 666 기준)와 d1(디렉터리, 777 기준)의 권한이 서로 다르게 나오는 이유를 처음 확인한 umask 값과 맞춰 본다. umask 077로 바꾼 뒤 만든 f2.txt·d2가 그룹·기타 권한이 전부 꺼진 채로 나오는지 비교한다.

왜 이걸 해보나: “umask 022일 때 새 디렉터리 권한은?” 같은 계산 문제에서 파일 기준(666)과 디렉터리 기준(777)을 혼동하는 것이 기출 단골 함정이다. 같은 umask에서 파일과 디렉터리 결과가 다르게 나오는 것을 직접 봐야 헷갈리지 않는다.

자주 틀리는 점

reference 기출·모의고사를 분석하면 이 단원은 시험에서 계산형 문항 비중이 가장 높은 단원이다. 반복되는 함정을 정리한다.

1. umask 계산을 파일과 디렉터리에 똑같이 적용. umask가 같아도 파일은 666, 디렉터리는 777에서 시작하므로 최종 결과가 다르다. “umask 022일 때 새 파일의 권한은?”과 “새 디렉터리의 권한은?”을 같은 값으로 답하면 틀린다(파일 644, 디렉터리 755).
2. SetUID(4)와 SetGID(2)를 헷갈림. “소유자 권한으로 실행”은 SetUID(4), “그룹 권한으로 실행 또는 그룹 상속”은 SetGID(2)다. reference 모의고사에서 2755(SetGID)를 SetUID의 8진수인 것처럼 서술하는 오답이 실제로 등장했다 — SetUID는 반드시 4로 시작해야 한다.
3. 스티키 비트를 파일에 적용하려는 오답. 스티키 비트는 “공유 디렉터리에서 남의 파일 삭제를 막는” 용도이므로 디렉터리에 걸어야 의미가 있다. “Sticky-Bit를 파일에 부여한다”는 선택지는 실효성이 없는 오답으로 자주 등장한다.
4. chmod의 재귀 옵션을 소문자 -r로 착각. 정답은 항상 대문자 -R이다.
5. chown 소유자:그룹 순서를 반대로 씀. 콜론 앞이 소유자, 뒤가 그룹이다.
6. 디렉터리의 x를 “그 디렉터리를 실행한다”는 뜻으로 잘못 서술. 디렉터리의 x는 실행이 아니라 진입(그 안의 항목을 이름으로 찾아 접근하는 것)을 의미한다.

핵심 정리

• 권한은 소유자·그룹·기타 세 부류로 나뉘며, 각 부류는 r(4)·w(2)·x(1) 3비트로 표현되고 이를 이어 붙인 것이 8진수 표기다.
• 기호 표기와 8진수 표기는 자리별로 4·2·1을 더하고 빼는 과정을 통해 서로 완전히 변환할 수 있으며, 변환 후에는 반드시 반대 방향으로 검산한다.
• umask는 파일 기본값 666, 디렉터리 기본값 777에서 umask 값이 지정한 비트를 “끄는” 방식으로 동작하며, 우연히 결과가 뺄셈과 같아 보일 뿐 실제로는 비트 연산이다.
• 특수 권한은 8진수 앞자리 SetUID(4)·SetGID(2)·스티키 비트(1)로 표현되며, 원래 실행 권한이 있었으면 소문자(s, t), 없었으면 대문자(S, T)로 표시된다.
• 디렉터리의 x는 그 디렉터리 안의 항목에 이름으로 접근(진입)할 수 있는 권한이며, 목록을 보는 r과는 독립적으로 작동한다.

마무리 복습

참고 자료

• GNU Coreutils 매뉴얼 
• Filesystem Hierarchy Standard (FHS)