리눅스 운영체제를 관리하고 서버를 안정적으로 운영하기 위해서 가장 먼저 마주하게 되는 벽이 바로 '보안과 권한'입니다. 특히 다중 사용자가 접속하는 서버 환경이나 자동화 스크립트가 실행되는 웹 서버 환경에서는 파일과 디렉토리의 권한을 꼼꼼하게 관리하지 않으면, 기밀 데이터가 외부에 노출되거나 시스템 설정 파일이 오염되는 치명적인 보안 사고로 이어질 수 있습니다.
리눅스 파일 시스템의 전통적인 권한 관리 방식인 chmod(권한 변경)와 chown(소유권 변경)부터, 이보다 훨씬 정교한 제어를 가능하게 하는 ACL(접근 제어 목록, Access Control List)까지 예제를 통해 깊이 있게 살펴보겠습니다.
리눅스에서 ls -l 명령어를 입력하면 파일 목록 왼쪽에 -rwxr-xr-x나 drwxrwxrwx 같은 알 수 없는 문자열을 보게 됩니다. 이것이 바로 리눅스 파일 시스템이 권한을 표시하는 정형화된 방식입니다.
이 문자열은 총 10자리로 구성되며 다음과 같은 규칙으로 쪼개어 해석할 수 있습니다.
첫 번째 자리 (파일 유형): -는 일반 파일, d는 디렉토리, l은 심볼릭 링크를 의미합니다.
2~4번째 자리 (소유자 권한, Owner/User): 파일을 생성한 사용자 본인이 가진 권한입니다.
5~7번째 자리 (그룹 권한, Group): 파일이 속한 그룹의 구성원들이 가진 권한입니다.
8~10번째 자리 (나머지 사용자 권한, Others): 소유자도 아니고 그룹 소유값에도 포함되지 않는 시스템의 모든 일반 사용자가 가진 권한입니다.
각 자리에는 r(Read, 읽기), w(Write, 쓰기), x(Execute, 실행) 권한이 표시되며, 해당 권한이 없을 경우 -로 채워집니다.
많은 초보자가 혼동하는 부분 중 하나는 파일에서의 권한과 디렉토리에서의 권한이 다르게 작동한다는 점입니다.
| 권한 | 파일에서의 의미 | 디렉토리에서의 의미 |
| r (읽기) | 파일의 본문 내용을 읽을 수 있음 (cat, vi 등) | 디렉토리 내부의 파일 목록을 볼 수 있음 (ls) |
| w (쓰기) | 파일의 본문 내용을 수정하거나 지울 수 있음 | 디렉토리 내부에 파일을 생성, 삭제, 이름 변경할 수 있음 |
| x (실행) | 바이너리나 스크립트 파일을 실행할 수 있음 | 디렉토리 내부로 진입할 수 있음 (cd) |
중요 포인트: 특정 파일의 내부 내용을 수정할 수 있는 권한(
w)이 파일 자체에 있더라도, 그 파일이 속한 상위 디렉토리에 쓰기(w) 권한이 없다면 사용자는 그 파일을 삭제하거나 이름을 바꿀 수 없습니다. 파일의 생성과 삭제는 디렉토리 권한의 지배를 받기 때문입니다.
chmod(Change Mode) 명령어는 파일이나 디렉토리의 읽기, 쓰기, 실행 권한을 수정할 때 사용합니다. 권한을 부여하는 방법은 크게 두 가지로 나뉩니다. 숫자를 이용한 8진수 표기법과 문자를 이용한 심볼릭 표기법입니다.
각 권한을 숫자로 환산하여 더한 값을 자릿수별로 부여하는 방식입니다. 빠르고 직관적이어서 실무에서 가장 애용됩니다.
r (읽기) = 4
w (쓰기) = 2
x (실행) = 1
권한 없음 = 0
이 숫자들을 조합하여 세 자리 숫자를 만듭니다. 예를 들어 소유자에게 읽기/쓰기/실행($4+2+1=7$), 그룹에게 읽기/실행($4+1=5$), 나머지에게 읽기/실행($4+1=5$)을 주고 싶다면 755가 됩니다.
자동화 셸 스크립트 파일(backup.sh)이 관리자만 수정할 수 있고, 그룹과 일반 사용자는 실행만 가능하도록 설정해야 하는 상황을 가정해 보겠습니다.
Bash
# 파일 상세 정보 확인
ls -l backup.sh
# 출력 예시: -rw-r--r-- 1 root root 1024 Jan 1 00:00 backup.sh
# 소유자(7: rwx), 그룹(5: r-x), 나머지(5: r-x) 권한 부여
chmod 755 backup.sh
# 결과 확인
ls -l backup.sh
# 출력 변경: -rwxr-xr-x 1 root root 1024 Jan 1 00:00 backup.sh
기존의 권한을 그대로 유지한 채 특정 대상의 권한만 정밀하게 조절하고 싶을 때 사용합니다. 대상 문자와 연산자를 조합합니다.
대상: u(user), g(group), o(others), a(all, 모두)
연산자: +(권한 추가), -(권한 제거), =(권한 강제 지정)
공동 프로젝트 디렉토리 안의 특정 설정 파일(config.json)에 대해, 기존 소유자 권한은 건드리지 않고 동일 그룹 팀원들에게만 수정 권한을 추가하고 외부인의 접근을 완전히 차단하는 경우입니다.
Bash
# 그룹(g)에게 쓰기(w) 추가, 나머지 사용자(o)에게서 읽기(r) 제거
chmod g+w,o-r config.json
보안 관리의 핵심은 권한을 좁히는 것뿐만 아니라, 해당 파일의 주인이 누구인지를 정확히 명시하는 것입니다. chown(Change Owner) 명령어는 파일과 디렉토리의 소유자와 소유 그룹을 변경합니다.
보통 웹 서버(Nginx, Apache)가 특정 디렉토리에 로그를 남기거나 업로드된 파일을 저장해야 할 때, 해당 디렉토리의 소유권을 웹 서버 실행 계정으로 넘겨주기 위해 자주 사용됩니다.
Bash
chown [옵션] 소유자:소유그룹 파일명(또는 디렉토리명)
시스템 관리자 계정(root)으로 웹 소스를 배포한 후, 사용자들이 이미지를 업로드할 수 있도록 uploads 디렉토리의 소유권을 웹 서버 계정인 www-data로 변경해야 하는 상황입니다. 디렉토리 내부의 하위 파일들까지 한 번에 바꾸려면 하위 순회 옵션인 -R(Recursive)을 반드시 붙여야 합니다.
Bash
# uploads 디렉토리와 그 내부 모든 파일의 소유자를 www-data로, 그룹도 www-data로 변경
chown -R www-data:www-data /var/www/html/uploads
# 변경 결과 확인
ls -ld /var/www/html/uploads
# 출력 예시: drwxr-xr-x 2 www-data www-data 4096 Jan 1 00:00 /var/www/html/uploads
기존의 chmod와 chown 구조는 매우 명확하고 가볍지만, 복잡한 조직 구조나 다중 협업 환경에서는 치명적인 한계에 부딪힙니다. 전통적인 방식으로는 단 한 명의 소유자와 단 하나의 소유 그룹만 지정할 수 있기 때문입니다.
회사의 개발 디렉토리 /project가 있습니다.
소유자는 팀장(manager)입니다.
소유 그룹은 개발팀(dev_group)입니다. 개발팀원들은 읽고 쓸 수 있어야 하므로 권한은 770으로 설정되어 있습니다.
이때, 기획팀의 planner01이라는 사원이 프로젝트 진척도를 확인하기 위해 이 디렉토리에 접근하여 '읽기만' 가능하도록 설정해 달라고 요청합니다. 기존 방식으로 풀려고 하면 딜레마에 빠집니다.
기획자를 dev_group에 넣어주면 기획자가 개발 소스를 수정하거나 삭제할 수 있게 되므로 보안 위배입니다.
나머지 사용자(others) 권한을 읽기 가능(775)으로 열어버리면, 회사 내 개발과 무관한 모든 일반 사원까지 소스코드를 들여다볼 수 있게 되므로 전사적 보안 실패로 이어집니다.
이처럼 "제3의 특정 사용자나 특정 그룹에게만 별도의 독립적인 권한을 부여하고 싶을 때" 사용하는 기술이 바로 ACL(접근 제어 목록)입니다.
ACL을 제어하는 핵심 명령어는 권한을 설정하는 setfacl과 설정된 권한을 확인하는 getfacl입니다. ACL이 적용된 파일은 ls -l로 확인했을 때 권한 표기 맨 뒤에 + 기호가 붙는 특징이 있습니다 (예: -rw-r--r--+).
Bash
getfacl /project
이 명령어를 입력하면 일반적인 ls보다 훨씬 상세하게 소유자, 그룹, 그리고 추가로 정의된 개별 사용자들의 권한 목록이 나타납니다.
가장 많이 쓰이는 옵션은 생성/수정을 뜻하는 -m(modify)과 삭제를 뜻하는 -x(remove)입니다.
앞서 제기된 문제를 ACL로 깔끔하게 해결해 보겠습니다. planner01 사용자에게만 /project 디렉토리의 읽기(r)와 진입(x) 권한을 개별적으로 부여합니다.
Bash
# 문법: setfacl -m u:[사용자명]:[권한] [대상]
setfacl -m u:planner01:rx /project
# 설정 상태 확인
getfacl /project
# 출력 결과 예시:
# # file: project
# # owner: manager
# # group: dev_group
# user::rwx
# user:planner01:r-x <-- 개별 사용자에 대한 권한이 추가됨을 확인 가능
# group::rwx
# mask::rwx
# other::---
이번에는 개발팀 디렉토리에 품질보증팀 전체 그룹(qa_group)이 들어와서 산출물을 검사할 수 있도록 읽기 권한을 통째로 부여하는 경우입니다.
Bash
# 문법: setfacl -m g:[그룹명]:[권한] [대상]
setfacl -m g:qa_group:rx /project
디렉토리에 권한을 주었어도, 그 안에서 새로운 파일이나 하위 디렉토리가 생성되면 기본 시스템 설정(umask)에 따른 기본 권한으로 파일이 만들어집니다. 이로 인해 새로 생긴 파일에는 기획자나 QA팀이 접근하지 못하는 현상이 발생합니다.
앞으로 생성될 모든 하위 파일에도 동일한 접근 제어 규칙을 자동으로 상속시키려면 디렉토리 자체에 d:(Default) 접두사를 붙여 ACL을 설정해야 합니다.
Bash
# 앞으로 /project 내부에 생성되는 모든 파일/폴더는 planner01에게 자동으로 rx 권한이 상속됨
setfacl -m d:u:planner01:rx /project
협업 기간이 끝나 기획자와 QA팀의 접근 권한을 다시 회수해야 할 때입니다.
Bash
# planner01 사용자에 대한 ACL 항목만 선택적 삭제
setfacl -x u:planner01 /project
# qa_group 그룹에 대한 ACL 항목만 선택적 삭제
setfacl -x g:qa_group /project
# 파일에 걸려있는 모든 ACL 설정을 초기화하고 전통적 권한 구조로 복구
setfacl -b /project
서버를 안전하게 격리하고 권한을 강화하기 위해 실무 관전에서 반드시 지켜야 할 체크리스트를 정리하며 글을 마무리하겠습니다.
최소 권한의 원칙 준수: 프로그램이나 사용자가 업무를 수행하는 데 필요한 최소한의 권한만 부여해야 합니다. 실행될 필요가 없는 설정 파일이나 데이터베이스 백업 파일 등은 절대로 x(실행) 권한을 주지 말고 600(-rw-------) 또는 640(-rw-r-----) 수준으로 꽁꽁 묶어두어야 합니다.
777 권한 남용 금지: 권한 오류나 웹 서버 업로드 오류가 발생했을 때 빠르고 귀찮다는 이유로 chmod 777을 주는 행동은 시스템의 대문을 열어두는 것과 같습니다. 무조건 소유권(chown)을 먼저 조정하고, 그래도 해결되지 않는 정교한 권한 분리는 setfacl을 통해 우아하게 해결하는 습관을 들여야 합니다.
정기적인 권한 감사: 외부 유입 파일이나 누군가 임시로 열어둔 권한이 방치되고 있지는 않은지 주기적으로 확인해야 합니다.
전통적인 chmod, chown으로 구조의 기틀을 단단히 다지고, 변칙적인 협업 상황 요구사항에는 ACL을 활용해 방어벽을 세운다면 외부 위협으로부터 시스템 자산과 데이터를 안전하게 지켜낼 수 있습니다.