파일 · 권한 · 사용자 관리 27 / 50 · Part 3. Linux 파일 권한
실습 환경: Rocky Linux 9.8 · Ubuntu 24.04.5 (Docker 격리 컨테이너, 테스트 계정analyst)
기초편 연계: 「리눅스 시스템 기초」 17. chown과 파일 소유권
그룹은 여러 사용자에게 같은 권한을 한 번에 부여 하는 수단이다. 개발팀 5명이 같은 디렉터리를 공유해야 한다면, 5개의 개별 권한 대신 그룹 하나로 관리한다.
이번 글에서는 파일의 그룹 소유권을 바꾸는 chgrp를 다룬다. 26편의 chown이 root 전용이었던 것과 달리, chgrp는 조건부로 일반 사용자도 할 수 있다. 그 조건 — 소유자이면서 대상 그룹의 구성원 — 을 실습으로 확인하고, 그룹 멤버십이 곧 권한이라는 보안 관점을 정리한다.
| 명령 | 동작 |
|---|---|
chgrp group file | 그룹 소유권 변경 |
chown :group file | 동일 |
chgrp -R group dir | 재귀 |
일반 사용자가 파일의 그룹을 바꾸려면 두 조건을 모두 만족해야 한다.
둘 중 하나라도 아니면 Operation not permitted. root는 이 제약을 받지 않는다.
| 종류 | 설명 | 확인 |
|---|---|---|
| 기본 그룹(primary) | 로그인 시 프로세스의 GID, 새 파일의 기본 그룹 | id -gn |
| 보조 그룹(supplementary) | 추가로 속한 그룹들 | id -Gn |
usermod -aG group user로 보조 그룹에 추가한다. -a(append)를 빠뜨리면 기존 보조 그룹이 모두 교체되므로 주의한다. (39편에서 상세)

그룹 변경 조건이 까다로운 이유는 chown과 같은 맥락이다. 아무 그룹으로나 바꿀 수 있다면, 사용자가 자기 파일을 자신이 속하지 않은 그룹 으로 옮겨 그 그룹의 쿼터를 소비하거나 접근 관계를 교란할 수 있다. 그래서 "내가 속한 그룹으로만" 바꾸도록 제한한다.
그룹 협업의 표준 구성은 다음과 같다.
groupadd project로 그룹 생성usermod -aG project alice로 구성원 추가chgrp project /shared로 공유 디렉터리 그룹 지정chmod 2775 /shared로 SGID 설정 — 이 디렉터리에 만들어지는 새 파일이 자동으로 project 그룹을 상속(29편)SGID가 없으면 각자 만든 파일이 각자의 기본 그룹을 갖게 되어 공유가 깨진다.
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

텍스트 원본(실제 출력):
[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
| 출력 | 해석 |
|---|---|
id → groups=1000(analyst),1001(project) | analyst는 project 구성원, web은 아님 |
chgrp project report.txt → analyst project | 소유자 + 구성원 조건 충족 → 성공 |
chgrp web report.txt → Operation not permitted | web 그룹 구성원이 아니라 거부 |
drwxrwsr-x ... shared | 그룹 실행 자리의 s = SGID |
shared/created-by-analyst → analyst project | analyst가 만들었지만 그룹이 project로 상속 됨 |
마지막 줄이 SGID의 효과다. SGID가 없었다면 이 파일의 그룹은 analyst가 됐을 것이고, project 팀원들이 그룹 권한으로 접근하지 못했을 것이다.
| 주제 | 내용 |
|---|---|
| 그룹 = 권한 묶음 | 사용자를 그룹에 넣는 것은 그 그룹의 모든 권한을 부여하는 것이다 |
| 위험한 그룹 | wheel/sudo(sudo 권한), docker(사실상 root), disk(디스크 직접 접근 = 파일 권한 우회), shadow(해시 읽기) |
| 최소 권한 | 필요한 그룹에만 넣는다. 편의로 넓은 그룹에 추가하지 않는다 |
| 공유 그룹 + 느슨한 umask | Ubuntu 002 umask + 공유 기본 그룹이면 그룹 전체가 서로 파일을 수정(25편) |
docker 그룹의 위험: docker 그룹 구성원은 컨테이너를 root로 띄우고 호스트 파일 시스템을 마운트할 수 있다. 즉 docker 그룹 = root 권한 이다(11편). 그룹 멤버십 점검 시 반드시 확인한다.
[점검] 민감 그룹 멤버십
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편) |
| 실수 | 결과 | 예방 |
|---|---|---|
| 속하지 않은 그룹으로 chgrp 시도 | 거부 | 먼저 그룹 가입 |
| SGID 없이 공유 디렉터리 운영 | 파일 그룹이 제각각 | 공유 디렉터리 2775 |
usermod -G에서 -a 누락 | 기존 보조 그룹 교체 | 항상 -aG |
| 편의로 docker/wheel 그룹 추가 | 사실상 root 부여 | 최소 권한 |
| 그룹 멤버십 미점검 | 은닉된 권한 상승 | 정기 점검 |
[ ] id 로 기본 그룹과 보조 그룹을 구분했다
[ ] 속한 그룹으로 chgrp 가 성공하는 것을 확인했다
[ ] 속하지 않은 그룹으로는 거부되는 것을 확인했다
[ ] SGID 디렉터리에서 새 파일이 그룹을 상속하는 것을 확인했다
[ ] usermod -aG 에서 -a 의 중요성을 안다
[ ] docker/wheel/disk 그룹의 위험성을 설명할 수 있다
chgrp는 소유자이면서 대상 그룹의 구성원 일 때만 일반 사용자도 가능하다.wheel/sudo·docker·disk·shadow 그룹은 사실상 강력한 권한이다.2775)로 새 파일의 그룹 상속을 보장한다.usermod로 보조 그룹 추가 시 항상 -aG를 쓴다.다음 글 「28. SUID 권한」 에서는 일반 사용자가 passwd로 자기 비밀번호를 바꿀 수 있는 이유 — SUID — 를 다룬다. SUID 파일이 소유자 권한으로 실행되는 원리와, 그것이 어떻게 권한 상승 공격의 핵심이 되는지 실습으로 확인한다.