2021년 한 클라우드 보안 조사팀이 공개 스토리지와 서버 설정을 대규모로 스캔했더니, 권한이 전체 공개로 풀려 있어 아무나 쓰기 가능한 디렉터리가 상당수 발견됐다는 보고가 나온 적이 있습니다(해당 스캔 조사 기준). 이런 사고는 대개 거창한 해킹 기술이 아니라 chmod 명령어 한 줄, 혹은 sudo 권한 하나를 잘못 내준 데서 시작돼요. 그렇다면 sudo, chmod, chown이 만드는 리눅스 권한 체계는 정확히 어떻게 작동하고, 실수는 보통 어디서 터지는 걸까요?
리눅스 파일 권한은 소유자·그룹·기타 사용자 세 단위로 나뉜다
리눅스의 모든 파일과 디렉터리는 소유자(owner), 소유 그룹(group), 그 외 모든 사용자(other) 이렇게 세 단위로 권한이 분리되어 관리돼요. ls -l 명령으로 파일 목록을 보면 맨 앞에 -rwxr-xr-x처럼 10글자짜리 문자열이 나오는데, 첫 글자는 파일 종류를 나타내고 그다음 9글자가 소유자·그룹·기타 순으로 3글자씩 묶여 각각의 읽기(r)·쓰기(w)·실행(x) 권한을 표시해요. 예를 들어 rwxr-xr-x라면 소유자는 세 권한을 다 가지고, 그룹과 기타 사용자는 읽기와 실행만 가능하다는 뜻이에요.
여기서 끝이 아니에요. 디렉터리에서는 실행 권한이 조금 다르게 해석되는데, 프로그램을 돌린다는 의미가 아니라 해당 디렉터리 안으로 들어가거나 내부 파일 목록에 접근할 수 있는지를 결정하는 권한이에요. 그래서 읽기 권한만 있고 실행 권한이 없는 디렉터리는 파일 이름 목록은 보여도 정작 그 안으로 들어갈 수는 없는 애매한 상태가 돼요.
rwx 권한은 8진수 숫자 하나로 표현할 수 있다
rwx 권한 조합은 읽기 4, 쓰기 2, 실행 1이라는 값을 더해서 8진수 숫자 하나로 표현할 수 있어요. 예를 들어 읽기와 쓰기만 있으면 4+2=6, 읽기와 실행만 있으면 4+1=5가 되고, 이 값을 소유자·그룹·기타 순서로 세 자리 이어 붙이면 흔히 보는 755나 644 같은 표기가 나와요. 755는 소유자에게 rwx(7)를 전부 주고 그룹과 기타에는 r-x(5)만 허용하는 조합이라 실행 파일이나 스크립트에 자주 쓰이고, 644는 소유자만 쓰기가 가능하고 나머지는 읽기만 되는 조합이라 일반 설정 파일이나 문서에 적합해요.
숫자 표기가 익숙해지면 chmod u+x처럼 기호로 권한을 더하거나 빼는 방식보다 훨씬 빠르게 의도를 전달할 수 있어요. 다만 숫자 하나 잘못 눌러서 6과 7을 헷갈리는 실수가 실무에서 은근히 자주 나오니, 스크립트에 chmod 명령을 넣을 때는 값을 한 번 더 확인하는 습관이 필요해요.
chmod와 chown은 서로 다른 대상을 바꾸는 명령어다
chmod는 파일의 권한 비트를 바꾸는 명령어이고 chown은 파일의 소유자와 소유 그룹을 바꾸는 명령어라는 점에서 역할 자체가 다르다는 걸 먼저 구분해야 해요. 권한을 아무리 755로 잘 맞춰도 소유자가 엉뚱한 계정으로 남아 있으면 원하는 사용자가 접근하지 못하는 상황이 생기기 때문에, 배포 스크립트나 서버 설정을 할 때는 두 명령을 같이 쓰는 경우가 많아요.
# 소유자에게 실행 권한만 추가
chmod u+x deploy.sh
# 8진수로 권한을 한 번에 지정
chmod 755 deploy.sh
# 소유자와 그룹을 동시에 변경
chown coti:developers app.log
# 디렉터리 하위 전체에 재귀적으로 적용
chown -R www-data:www-data /var/www/htmlsudo와 su는 권한을 위임하는 방식이 다르다
sudo는 자신의 비밀번호로 특정 명령 하나를 관리자 권한으로 일시 실행하는 방식이고, su는 아예 다른 사용자 계정, 주로 root로 로그인 세션 자체를 전환하는 방식이라는 점에서 근본적으로 달라요. sudo는 /etc/sudoers 설정에 따라 어떤 사용자가 어떤 명령까지 쓸 수 있는지 세밀하게 제한할 수 있고, 실행한 명령이 로그로 남아 나중에 누가 무엇을 했는지 추적할 수 있다는 장점이 있어요. 반면 su로 root 세션에 들어가 버리면 그 안에서 실행한 개별 명령까지는 기록되지 않아서, 문제가 생겼을 때 원인을 되짚기가 훨씬 어려워져요.
그래서 최근 배포판들은 root 계정 자체를 기본으로 잠가두고 sudo만 열어두는 쪽을 표준으로 삼고 있습니다(Ubuntu·Fedora 기본 설정 기준). sudoers 파일을 손볼 일이 있다면 반드시 visudo 명령으로 열어야 하는데, 문법 오류가 있으면 저장 전에 걸러주기 때문이에요.
잘못된 권한 설정은 실제로 보안 사고로 이어진다
잘못 설정된 권한은 이론상의 위험이 아니라 실제로 서버가 뚫리는 직접적인 원인이 돼요. 가장 흔한 사례가 웹 루트 디렉터리를 chmod 777로 풀어버리는 경우인데, 이렇게 하면 서버에 접속할 수 있는 누구나 파일을 덮어쓸 수 있어서 공격자가 웹쉘 하나만 올려도 원격 코드 실행으로 바로 이어져요. /etc/shadow처럼 비밀번호 해시가 담긴 파일이 실수로 world-readable 상태가 되는 것도 비슷한 맥락의 사고이고, 여기에 SUID 비트가 잘못 설정된 실행 파일까지 겹치면 일반 계정에서 root 권한으로 뛰어오르는 권한 상승 공격의 통로가 열려버려요.
실제로 Kali Linux를 활용한 모의 침투 점검에서도 world-writable 디렉터리나 SUID가 걸린 바이너리부터 스캔하는 게 기본 절차 중 하나예요. 접근 통제로 문제를 막는 이런 방식과 달리, 애초에 프로세스와 애플리케이션을 물리적으로 격리해버리는 Qubes·Tails 같은 보안 중심 배포판은 권한 설정 실수 자체의 파급력을 줄이는 완전히 다른 접근을 택하고 있어요.
권한을 안전하게 관리하려면 어떤 원칙을 지켜야 하는가
권한 관리의 기본 원칙은 필요한 최소한의 권한만 내주는 최소 권한 원칙이에요. 임시방편으로 chmod 777을 쓰는 대신 그룹을 만들어 필요한 사용자만 그룹에 추가하고 775나 664처럼 좁은 범위로 권한을 주는 방식이 훨씬 안전하고, sudo 사용 기록은 journalctl이나 /var/log/auth.log에서 주기적으로 확인하는 습관을 들이는 게 좋아요. 네트워크 단에서 ufw·firewalld·nftables 같은 방화벽으로 불필요한 접근을 막는 것과 마찬가지로, 파일 권한 관리도 결국 다층 방어의 한 축이라는 관점으로 접근해야 해요.
결국 서버 보안 사고의 상당수는 화려한 취약점이 아니라 권한 설정 한 줄에서 시작돼요. sudo와 chmod, chown이 만드는 이 단순한 삼각 구조를 정확히 이해하고 지키는 것만으로도, 처음 언급했던 것처럼 전체 공개로 뚫려 있는 디렉터리를 만드는 실수는 충분히 막을 수 있어요.
자주 묻는 질문
Q1. chmod 777은 왜 위험한가요?
chmod 777은 소유자, 그룹, 그 외 모든 사용자에게 읽기·쓰기·실행 권한을 전부 열어주는 설정이라서 서버에 접속할 수 있는 누구나 해당 파일을 마음대로 수정하거나 악성 코드로 바꿔치기할 수 있게 돼요.
Q2. sudo 없이 root로 계속 로그인해서 작업해도 되나요?
권장하지 않아요, root로 상시 로그인하면 명령어 하나의 실수가 시스템 전체에 즉시 영향을 주고 누가 무엇을 했는지 기록도 남지 않아서 문제 추적이 어려워져요.
Q3. 디렉터리 권한과 파일 권한은 같은 방식으로 해석되나요?
아니요, 디렉터리에서 실행(x) 권한은 프로그램 실행이 아니라 그 디렉터리 안으로 들어가거나 파일 목록에 접근할 수 있는지를 결정한다는 점에서 파일의 실행 권한과 의미가 달라요.
Q4. chmod 755와 644는 각각 언제 쓰나요?
755는 소유자에게 모든 권한을 주고 그룹과 기타 사용자에게는 읽기·실행만 허용하는 조합이라 실행 파일이나 디렉터리에 주로 쓰고, 644는 소유자만 쓰기가 가능하고 나머지는 읽기만 되는 조합이라 일반 문서나 설정 파일에 적합해요.
Q5. sudoers 파일은 왜 직접 편집하면 안 되나요?
sudoers 파일은 문법 오류가 하나만 있어도 sudo 명령 자체가 먹통이 될 수 있어서, 반드시 visudo 명령으로 열어 문법 검사를 거친 뒤 저장해야 안전해요.
Q6. 권한 문제를 예방하려면 가장 먼저 무엇을 점검해야 하나요?
가장 먼저 world-writable로 열려 있는 파일과 디렉터리, 그리고 불필요한 SUID 비트가 설정된 실행 파일이 있는지부터 점검하는 게 우선이에요.
BFQ 비디오 재생 벤치마크: 반응성을 높인 대가로 프레임이 얼마나 떨어졌나
BFQ+의 low-latency 휴리스틱이 반응성을 높이는 대신 소프트 실시간 애플리케이션에 어떤 지연 시간 대가를 요구하는지 논문의 비디오 재생 벤치마크로 확인합니다.
NCQ가 켜지면 디스크 스케줄러 보장이 무너지는 이유 (BFQ 논문 실측)
Native Command Queueing이 활성화되면 BFQ, CFQ 같은 OS 스케줄러의 공정성·지연 보장이 어떻게 무력화되는지 논문의 실측 데이터로 설명합니다.
BFQ+ vs BFQ vs CFQ 실측 벤치마크: 처리량과 앱 기동 시간 비교
BFQ 논문이 세 대의 리눅스 시스템에서 실측한 집계 처리량과 bash·konsole 기동 시간 벤치마크 결과를 수치 그대로 정리합니다.