파일 · 권한 · 사용자 관리 27 / 50 · Part 3. Linux 파일 권한
실습 환경: Rocky Linux 9.8 · Ubuntu 24.04.5 (Docker 격리 컨테이너, 테스트 계정 analyst)
기초편 연계: 「리눅스 시스템 기초」 17. chown과 파일 소유권

1. 들어가며

그룹은 여러 사용자에게 같은 권한을 한 번에 부여 하는 수단이다. 개발팀 5명이 같은 디렉터리를 공유해야 한다면, 5개의 개별 권한 대신 그룹 하나로 관리한다.

이번 글에서는 파일의 그룹 소유권을 바꾸는 chgrp를 다룬다. 26편의 chown이 root 전용이었던 것과 달리, chgrp는 조건부로 일반 사용자도 할 수 있다. 그 조건 — 소유자이면서 대상 그룹의 구성원 — 을 실습으로 확인하고, 그룹 멤버십이 곧 권한이라는 보안 관점을 정리한다.


2. 핵심 개념

2-1. chgrp와 chown :group

명령동작
chgrp group file그룹 소유권 변경
chown :group file동일
chgrp -R group dir재귀

2-2. 그룹 변경 조건

일반 사용자가 파일의 그룹을 바꾸려면 두 조건을 모두 만족해야 한다.

  1. 파일의 소유자 여야 한다.
  2. 바꾸려는 그룹의 구성원 이어야 한다.

둘 중 하나라도 아니면 Operation not permitted. root는 이 제약을 받지 않는다.

2-3. 기본 그룹과 보조 그룹

종류설명확인
기본 그룹(primary)로그인 시 프로세스의 GID, 새 파일의 기본 그룹id -gn
보조 그룹(supplementary)추가로 속한 그룹들id -Gn

usermod -aG group user로 보조 그룹에 추가한다. -a(append)를 빠뜨리면 기존 보조 그룹이 모두 교체되므로 주의한다. (39편에서 상세)


3. 동작 원리

chgrp — 그룹 기반 접근 제어

그룹 변경 조건이 까다로운 이유는 chown과 같은 맥락이다. 아무 그룹으로나 바꿀 수 있다면, 사용자가 자기 파일을 자신이 속하지 않은 그룹 으로 옮겨 그 그룹의 쿼터를 소비하거나 접근 관계를 교란할 수 있다. 그래서 "내가 속한 그룹으로만" 바꾸도록 제한한다.

그룹 협업의 표준 구성은 다음과 같다.

  1. groupadd project로 그룹 생성
  2. usermod -aG project alice로 구성원 추가
  3. chgrp project /shared로 공유 디렉터리 그룹 지정
  4. chmod 2775 /shared로 SGID 설정 — 이 디렉터리에 만들어지는 새 파일이 자동으로 project 그룹을 상속(29편)

SGID가 없으면 각자 만든 파일이 각자의 기본 그룹을 갖게 되어 공유가 깨진다.


4. 명령어 실습

analyst는 project 그룹의 구성원이지만 web 그룹은 아니다. shared는 SGID(2775)가 설정된 공유 디렉터리다.

cd /data/lab27

# 1) 내 그룹 확인
id                                 # groups 에 project 포함, web 없음
ls -l report.txt                   # analyst:analyst 소유

# 2) 속한 그룹으로는 변경 성공
chgrp project report.txt && ls -l report.txt

# 3) 속하지 않은 그룹으로는 실패
chgrp web report.txt               # Operation not permitted

# 4) SGID 공유 디렉터리 — 새 파일이 그룹 상속
ls -ld shared                      # drwxrwsr-x (s = SGID)
touch shared/created-by-analyst && ls -l shared/created-by-analyst

5. 실행 결과

실제 실행 결과 — Rocky Linux 9.8 · analyst@rocky9-lab — chgrp 조건과 그룹 상속

텍스트 원본(실제 출력):

[analyst@rocky9-lab ~]$ cd /data/lab27
[analyst@rocky9-lab lab27]$ id
uid=1000(analyst) gid=1000(analyst) groups=1000(analyst),1001(project)
[analyst@rocky9-lab lab27]$ ls -l report.txt
-rw-rw-r-- 1 analyst analyst 3 Sep 24 10:57 report.txt
[analyst@rocky9-lab lab27]$ chgrp project report.txt && ls -l report.txt
-rw-rw-r-- 1 analyst project 3 Sep 24 10:57 report.txt
[analyst@rocky9-lab lab27]$ chgrp web report.txt 2>&1 || echo "→ 소속되지 않은 그룹으로는 변경 불가"
chgrp: changing group of 'report.txt': Operation not permitted
→ 소속되지 않은 그룹으로는 변경 불가
[analyst@rocky9-lab lab27]$ ls -ld shared
drwxrwsr-x 2 root project 4096 Sep 24 10:57 shared
[analyst@rocky9-lab lab27]$ touch shared/created-by-analyst && ls -l shared/created-by-analyst
-rw-r--r-- 1 analyst project 0 Sep 24 10:57 shared/created-by-analyst

6. 결과 해석

출력해석
id → groups=1000(analyst),1001(project)analyst는 project 구성원, web은 아님
chgrp project report.txt → analyst project소유자 + 구성원 조건 충족 → 성공
chgrp web report.txt → Operation not permittedweb 그룹 구성원이 아니라 거부
drwxrwsr-x ... shared그룹 실행 자리의 s = SGID
shared/created-by-analyst → analyst projectanalyst가 만들었지만 그룹이 project로 상속 됨

마지막 줄이 SGID의 효과다. SGID가 없었다면 이 파일의 그룹은 analyst가 됐을 것이고, project 팀원들이 그룹 권한으로 접근하지 못했을 것이다.


7. 보안 관점

주제내용
그룹 = 권한 묶음사용자를 그룹에 넣는 것은 그 그룹의 모든 권한을 부여하는 것이다
위험한 그룹wheel/sudo(sudo 권한), docker(사실상 root), disk(디스크 직접 접근 = 파일 권한 우회), shadow(해시 읽기)
최소 권한필요한 그룹에만 넣는다. 편의로 넓은 그룹에 추가하지 않는다
공유 그룹 + 느슨한 umaskUbuntu 002 umask + 공유 기본 그룹이면 그룹 전체가 서로 파일을 수정(25편)

docker 그룹의 위험: docker 그룹 구성원은 컨테이너를 root로 띄우고 호스트 파일 시스템을 마운트할 수 있다. 즉 docker 그룹 = root 권한 이다(11편). 그룹 멤버십 점검 시 반드시 확인한다.


8. 보안관제 관점

[점검]   민감 그룹 멤버십
   getent group wheel sudo docker disk shadow adm
   for g in wheel sudo docker disk; do echo "== $g =="; getent group $g; done
     ↓
[판단]   업무상 필요 없는 계정이 민감 그룹에 있는가?
     ↓
[Evidence] /etc/group 변경 시각, usermod 실행 로그(secure/auth.log)
     ↓
[Response] 불필요한 멤버십 제거(gpasswd -d user group), 변경 경위 조사
관점내용
Detection/etc/group·/etc/gshadow 변경, usermod/gpasswd 실행을 감시
권한 상승 흔적공격자가 자신을 wheel/sudo/docker 그룹에 추가하는 것은 흔한 지속성 기법
Baseline그룹별 정상 구성원 목록을 기준값으로 두고 이탈을 탐지(48편)

9. 실무에서 자주 발생하는 실수

실수결과예방
속하지 않은 그룹으로 chgrp 시도거부먼저 그룹 가입
SGID 없이 공유 디렉터리 운영파일 그룹이 제각각공유 디렉터리 2775
usermod -G에서 -a 누락기존 보조 그룹 교체항상 -aG
편의로 docker/wheel 그룹 추가사실상 root 부여최소 권한
그룹 멤버십 미점검은닉된 권한 상승정기 점검

10. 실습 체크리스트

[ ] id 로 기본 그룹과 보조 그룹을 구분했다
[ ] 속한 그룹으로 chgrp 가 성공하는 것을 확인했다
[ ] 속하지 않은 그룹으로는 거부되는 것을 확인했다
[ ] SGID 디렉터리에서 새 파일이 그룹을 상속하는 것을 확인했다
[ ] usermod -aG 에서 -a 의 중요성을 안다
[ ] docker/wheel/disk 그룹의 위험성을 설명할 수 있다

11. 핵심 정리

  • chgrp는 소유자이면서 대상 그룹의 구성원 일 때만 일반 사용자도 가능하다.
  • 그룹은 여러 사용자에게 권한을 한 번에 주는 수단이다. 멤버십 = 권한이다.
  • wheel/sudo·docker·disk·shadow 그룹은 사실상 강력한 권한이다.
  • 그룹 협업 디렉터리는 SGID(2775)로 새 파일의 그룹 상속을 보장한다.
  • usermod로 보조 그룹 추가 시 항상 -aG를 쓴다.
  • 민감 그룹 멤버십을 정기 점검하고, 무단 추가를 권한 상승 흔적으로 본다.

12. 다음 편 예고

다음 글 「28. SUID 권한」 에서는 일반 사용자가 passwd로 자기 비밀번호를 바꿀 수 있는 이유 — SUID — 를 다룬다. SUID 파일이 소유자 권한으로 실행되는 원리와, 그것이 어떻게 권한 상승 공격의 핵심이 되는지 실습으로 확인한다.


참고 자료


시리즈 이동

profile
코드에 숨겨진 위협을 읽고 AI로 보안의 미래를 설계합니다. 프론트엔드 개발 경험을 자산 삼아 더 견고하고 지능적인 보안 운영 시스템을 구축해 나가는 과정을 기록합니다

0개의 댓글