SetUID·SetGID·스티키비트, rwsr-xr-x 한 번에 읽는 법
"ls -l 쳤는데 rwsr-xr-x처럼 처음 보는 글자가 껴 있어요. 오타인 줄 알았어요."
리눅스 퍼미션을 r, w, x 세 글자로 외운 사람이라면 한 번쯤 겪는 순간이다. 분명 실행 권한 자리인데 x 대신 s가, 어떤 파일은 t가 박혀 있다. 교재를 봐도 "특수 권한"이라는 이름만 던져주고 왜 필요한지는 설명이 부족한 경우가 많다.
진짜 걸림돌은 이거다. 특수 권한은 **"누구 권한으로 실행되는가"**와 **"누가 지울 수 있는가"**를 바꾸는 예외 규칙인데, 기본 퍼미션(rwx)의 연장선으로만 외우려니 헷갈리는 것이다. 이 글을 다 읽으면 rwsr-xr-x 같은 문자열을 보자마자 "아, 이 파일은 실행할 때 소유자 권한을 빌려 쓰는구나"라고 바로 판별할 수 있게 된다.
기본 퍼미션의 한계, 그리고 특수 권한이 등장한 이유
리눅스의 기본 퍼미션은 소유자(owner)·그룹(group)·기타(other) 세 주체에 대해 각각 읽기(r)·쓰기(w)·실행(x) 권한을 부여한다. 예를 들어 일반 파일이 -rwxr-xr-x라면 "소유자는 읽고 쓰고 실행, 그룹과 기타는 읽고 실행만 가능"이라는 뜻이다. 여기까지는 대부분의 수험생이 익숙하다.
문제는 이 구조로는 풀 수 없는 상황이 실무에 있다는 점이다. 대표적인 예가 비밀번호 변경이다. 일반 사용자는 자신의 비밀번호를 바꾸고 싶어 하지만, 비밀번호가 저장된 /etc/shadow 파일은 root만 쓸 수 있게 잠겨 있다. 일반 사용자에게 /etc/shadow 쓰기 권한을 직접 열어주면 보안이 무너진다. 그렇다고 비밀번호를 못 바꾸게 할 수도 없다.
이럴 때 쓰는 것이 특수 권한이다. 비유하자면 회사 정문에 "평소엔 사원증이 있어야 들어가지만, 이 특정 창구(passwd 프로그램)를 통해서만은 방문객도 관리자 대행 자격으로 서류함(shadow 파일)에 접근하게 해주는 임시 통행증"을 발급하는 것과 같다. 통행증은 그 창구를 이용할 때만 유효하고, 창구를 벗어나면 사라진다.
정확한 용어로 정리하면 특수 권한은 세 가지다.
- SetUID(Set User ID): 실행 파일에 걸리며, 실행 시 실행한 사용자가 아니라 파일 소유자의 권한으로 프로세스가 동작하게 한다.
- SetGID(Set Group ID): 실행 파일에 걸리면 파일 소유 그룹 권한으로 동작하게 하고, 디렉토리에 걸리면 그 안에서 새로 만든 파일이 디렉토리의 그룹을 물려받게 한다.
- 스티키 비트(Sticky Bit): 디렉토리에 걸리며, 누구나 쓸 수 있는 공용 디렉토리에서도 자기 파일은 자기(또는 root)만 지울 수 있게 제한한다.
세 가지 모두 표시 방식이 같은 원리를 공유한다. 원래 x가 들어갈 자리에 s 또는 t가 겹쳐 쓰인다. 아래 그림처럼 SetUID는 소유자의 x 자리, SetGID는 그룹의 x 자리, 스티키 비트는 기타의 x 자리에 나타난다.
여기서 대문자/소문자 구분이 시험에 자주 나온다. 원래 그 자리에 실행 권한(x)이 있었으면 소문자(s, t)로 표시되고, 실행 권한이 없었으면 대문자(S, T)로 표시된다. 대문자로 보인다는 건 "특수 권한은 있는데 애초에 실행 권한 자체가 없어서 의미가 무효화됐다"는 신호다.
시험에 자주 나오는 함정
rwSr--r--는 SetUID가 설정되지 않은 일반 파일이다.
틀렸다. 대문자 S도 SetUID가 설정된 상태다. 다만 소유자의 실행 권한(x)이 없어서 s가 아니라 S로 표시될 뿐이다. "대문자니까 특수 권한이 없다"고 착각하면 틀리는 대표 문제다.
SetUID, 남의 신발을 신고 뛰는 프로그램
SetUID를 이해하는 가장 쉬운 방법은 실제 명령어 하나를 끝까지 따라가 보는 것이다. passwd 명령어가 정확히 이 구조로 동작한다.
일반 사용자가 passwd를 실행하면 무슨 일이 벌어지는지 순서대로 보자. 첫째, 사용자는 자신의 UID(예: 1000)로 로그인해 있다. 둘째, passwd 실행 파일은 소유자가 root이고 SetUID 비트가 설정돼 있다. 셋째, 이 프로그램을 실행하는 순간 프로세스의 유효 사용자 ID(EUID) 가 실행한 사람의 UID가 아니라 파일 소유자인 root(UID 0)로 바뀐다. 넷째, 그 결과 이 프로세스는 root만 쓸 수 있는 /etc/shadow에 새 비밀번호 해시를 기록할 수 있게 된다.
여기서 핵심은 "누가 실행했는가(Real UID)"와 "누구 권한으로 동작하는가(Effective UID)"가 분리된다는 점이다. 평소엔 이 둘이 같지만, SetUID가 걸린 프로그램을 실행하는 순간만 EUID가 파일 소유자로 바뀐다. 이 전환은 그 프로그램이 실행되는 동안에만 유효하고, 프로그램이 끝나면 사라진다. 통행증이 창구를 나서면 무효가 되는 것과 같은 이치다.
SetUID를 설정하는 명령은 chmod u+s 파일명 또는 숫자 표기에서 맨 앞자리에 4를 붙이는 방식(chmod 4755 파일명)을 쓴다. 숫자 표기의 원리는 다른 편(퍼미션 숫자와 umask 계산)에서 자세히 다룬다.
시험에 자주 나오는 함정
SetUID가 설정된 파일은 어떤 사용자가 실행해도 root 계정 자체로 로그인된다.
틀렸다. 로그인 세션이 바뀌는 게 아니라, 그 프로그램이 실행되는 동안의 프로세스 권한만 파일 소유자 권한으로 동작하는 것이다. 프로그램이 종료되면 원래 사용자 권한으로 돌아온다. "권한 상승 = 계정 전환"으로 오해하면 틀리는 선지다.
SetGID, 그룹 단위로 협업할 때 쓰는 열쇠
SetGID는 SetUID와 원리는 같지만 적용 대상이 사용자가 아니라 그룹이라는 점, 그리고 파일과 디렉토리에서 동작이 다르다는 점이 다르다.
파일에 SetGID가 설정되면 SetUID와 마찬가지로 실행 시 소유 그룹의 권한으로 프로세스가 동작한다. 예를 들어 wall처럼 여러 사용자에게 메시지를 broadcast하는 일부 유틸리티가 특정 그룹 권한이 필요한 작업(터미널 장치 파일에 쓰기 등)을 수행할 때 이런 방식이 쓰인다.
더 자주 시험에 나오는 쪽은 디렉토리에 걸린 SetGID다. 여러 사용자가 협업하는 공유 디렉토리를 생각해 보자. 사용자 A와 B가 같은 프로젝트 그룹(dev)에 속해 있고, 공유 디렉토리 /project에 SetGID가 설정돼 있다면, A든 B든 그 디렉토리 안에서 새 파일을 만들 때 파일의 그룹 소유권이 자동으로 dev가 된다. SetGID가 없다면 파일 생성자의 기본 그룹이 그대로 적용돼, 협업자가 만든 파일을 다른 팀원이 열지 못하는 상황이 생길 수 있다.
설정 명령은 chmod g+s 디렉토리 또는 숫자 표기 맨 앞자리에 2를 붙인다(chmod 2775 디렉토리).
시험에 자주 나오는 함정
SetGID는 디렉토리에는 적용할 수 없고 실행 파일에만 적용된다.
틀렸다. 오히려 실무·시험 모두에서 디렉토리에 적용하는 SetGID가 더 자주 다뤄진다. SetUID는 디렉토리에 걸어도 의미가 없지만, SetGID는 디렉토리에 걸렸을 때 그룹 상속이라는 뚜렷한 효과가 있다는 차이를 기억해야 한다.
스티키 비트, 공용 폴더의 질서 유지 장치
마지막은 스티키 비트다. 앞의 두 개와 달리 스티키 비트는 "누구 권한으로 실행되는가" 문제가 아니라 "누가 삭제할 수 있는가" 문제를 다룬다.
가장 널리 알려진 예시가 /tmp 디렉토리다.
/tmp는 시스템의 모든 사용자가 임시 파일을 만들 수 있어야 하므로 기타(other) 권한까지 rwx로 활짝 열려 있다. 그런데 이 상태 그대로라면 논리적으로 이상한 일이 생긴다. 디렉토리에 쓰기 권한이 있다는 건 "그 안의 파일을 지울 권한"도 포함하는데, 그러면 사용자 A가 만든 파일을 사용자 B가 마음대로 지울 수 있다는 뜻이 된다. 여러 사람이 쓰는 창고인데 자물쇠가 하나도 없는 셈이다.
스티키 비트는 이 구멍을 막는다. 디렉토리에 스티키 비트가 설정되면, 그 디렉토리에 쓰기 권한이 있는 사용자라도 자기가 소유한 파일이 아니면 지울 수 없다. 오직 파일 소유자와 root만 삭제·이름변경이 가능하다.
시험에 자주 나오는 함정
스티키 비트가 설정된 디렉토리에서는 소유자가 아니면 파일을 읽을 수도 없다.
틀렸다. 스티키 비트는 삭제·이름변경 권한만 제한한다. 읽기·쓰기(내용 수정)는 원래 그 파일에 걸린 기본 퍼미션을 그대로 따른다. "삭제 제한"과 "접근 제한"을 같은 것으로 착각하게 만드는 전형적인 함정이다.
특수 권한 파일을 찾고 점검하는 법
세 가지 특수 권한의 원리를 익혔다면, 실무·시험 양쪽에서 자주 붙는 질문이 하나 더 있다. "시스템에 지금 SetUID가 걸린 파일이 몇 개나 있는지, 어떻게 확인하나?"이다.
find 명령어의 -perm 옵션으로 이 확인이 가능하다.
-perm -4000에서 4000은 SetUID 비트를 숫자로 표현한 것이다(SetUID=4000, SetGID=2000, 스티키 비트=1000 — 앞서 본 숫자 표기 4xxx, 2xxx, 1xxx의 맨 앞자리와 같은 값이다). -perm 뒤에 하이픈(-)을 붙이면 "이 비트를 포함하는 모든 권한"을 찾으라는 뜻이 되어, 뒤의 하위 세 자리(소유자·그룹·기타 권한)와 무관하게 해당 특수 권한만 걸려 있으면 걸러낸다.
이 명령이 시험에 나오는 이유는 단순 문법 암기가 아니라 보안 점검의 맥락과 엮여 있기 때문이다. SetUID가 걸린 실행 파일이 늘어날수록 공격자가 악용할 수 있는 경로(권한 상승 취약점)도 늘어난다. 그래서 시스템 관리자는 주기적으로 SetUID 파일 목록을 점검하고, passwd처럼 꼭 필요한 경우가 아니면 SetUID를 제거하는 것이 권장된다. "왜 이 명령을 쓰는가"까지 연결해서 기억해 두면 응용문제에도 흔들리지 않는다.
시험에 자주 나오는 함정
find / -perm 4000 -type f (하이픈 없이)와 find / -perm -4000 -type f (하이픈 포함)는 결과가 같다.
틀렸다. 하이픈이 없는 -perm 4000은 권한이 정확히 4000과 일치하는 파일만 찾는다(즉 SetUID만 있고 나머지 rwx는 전부 0인, 사실상 존재하기 힘든 파일). 반면 하이픈이 있는 -perm -4000은 "SetUID 비트를 포함하기만 하면" 나머지 권한 값과 무관하게 찾는다. 실무에서 SetUID 파일을 점검할 때는 항상 하이픈을 붙인 형태를 쓴다.
시험 직전에 이것만
- s는 실행 권한 있고 특수 권한도 있음, S는 실행 권한만 없는 것.
- SetUID는 "누구 권한으로 도나", 스티키 비트는 "누가 지우나".
- SetGID 디렉토리는 하위 파일 그룹을 자동 상속한다.
『빠르게 따는 리눅스마스터 2급』에서 더 보기
특수 권한 3종은 리눅스마스터 2급 1차(필기) 시험에서 파일 시스템·권한 관리 영역의 단골 출제 포인트다. 『빠르게 따는 리눅스마스터 2급』에서도 이 개념을 다루고 있다.
이 시리즈의 다른 책들과 마찬가지로 1권과 2권의 역할이 나뉘어 있다. 1권에서는 SetUID·SetGID·스티키 비트가 왜 필요한지부터 개념을 차근차근 설명하고 passwd, /tmp 같은 실제 예시로 풀어간다. 2권은 "테마" 단위로 압축된 빈출 족보라, 시험 직전에 rws, rwt 표기와 숫자 표기(4/2/1)만 빠르게 다시 확인하는 용도로 쓰면 된다.
🖥️ 골든래빗 CBT에서 리눅스마스터 2급 문제 풀어보기
궁금한 게 생기면 『빠따 리눅스마스터』 공식 카카오톡 질문방에서 물어보세요. 저자들이 직접 답합니다.