파일 · 권한 · 사용자 관리 39 / 50 · Part 4. 사용자와 그룹 관리
실습 환경: Rocky Linux 9.8 · Ubuntu 24.04.5 (Docker 격리 컨테이너, 테스트 계정analyst)
기초편 연계: 「리눅스 시스템 기초」 18. Linux 사용자와 그룹
1. 들어가며
34편에서 기본 그룹과 보조 그룹의 정의 를 봤다. 이번 글에서는 로그인 세션에서 이 둘이 실제로 어떻게 작동하는지 를 다룬다.
핵심 질문 두 가지:
- 여러 그룹에 속한 사용자가 파일을 만들면 어느 그룹 이 붙는가?
- 로그인한 뒤 유효 그룹을 바꿀 수 있는가?
답을 미리 말하면, 새 파일의 그룹은 기본 그룹 하나 로 정해진다(SGID 디렉터리 예외). 그리고 newgrp로 유효 그룹을 전환할 수 있다. 이 원리를 알면 그룹 협업 디렉터리를 왜 SGID로 구성하는지(29편) 완전히 이해된다.
2. 핵심 개념
2-1. 기본 그룹과 보조 그룹
| 구분 | 개수 | 역할 |
|---|---|---|
| 기본 그룹(primary) | 항상 1개 | 새 파일의 그룹, 프로세스의 egid |
| 보조 그룹(supplementary) | 0개~다수 | 추가 접근 권한 |
프로세스는 기본 그룹 하나(egid)와 보조 그룹 여러 개를 동시에 가진다.
2-2. 권한 검사 vs 새 파일 그룹
두 가지를 구분해야 한다.
- 권한 검사: 커널은 파일 그룹을 프로세스의 기본 + 모든 보조 그룹 과 비교한다. 그중 하나라도 일치하면 그룹 권한이 적용된다.
- 새 파일 그룹: 파일을 만들면 그 파일의 그룹은 프로세스의 기본 그룹(egid) 하나 로 정해진다.
즉, 접근은 여러 그룹으로 되지만 생성은 한 그룹으로 된다. 이 비대칭이 협업의 문제를 만든다.
2-3. newgrp
newgrp <group>은 새 셸을 열어 유효 그룹(egid)을 지정 그룹으로 전환 한다. 자신이 속한 그룹으로만 전환할 수 있다. 이후 만드는 파일은 그 그룹을 갖는다.
3. 동작 원리
multiuser가 developers, auditors 보조 그룹에 속한다고 하자. multiuser가 파일을 만들면 그 파일의 그룹은 기본 그룹(multiuser)이 된다. developers 팀원이 그 파일을 그룹 권한으로 열려 해도, 파일 그룹이 developers가 아니라 접근하지 못한다.
해결책은 두 가지다.
- newgrp:
newgrp developers후 파일을 만들면 그룹이developers가 된다. 하지만 매번 전환해야 해서 번거롭다. - SGID 디렉터리(29편): 공유 디렉터리에 SGID를 걸면, 그 안의 새 파일이 디렉터리의 그룹을 상속 한다.
newgrp없이도 자동으로 올바른 그룹이 붙는다.
실무에서는 SGID 디렉터리가 표준이다. chmod 2770 /shared로 만든 developers 그룹 디렉터리에서는, multiuser가 만든 파일도 자동으로 developers 그룹을 갖는다.
4. 명령어 실습
multiuser는developers·auditors보조 그룹에 속한다./data/dev-area는developers그룹의 SGID(2770) 디렉터리다. root 권한 실습이다.
# 1) multiuser 의 그룹 구성
id multiuser
echo "기본 그룹(gid=): $(id -gn multiuser) / 보조 그룹: $(id -Gn multiuser)"
# 2) SGID 디렉터리에 파일 생성 → 그룹 상속
su - multiuser -c 'touch /data/dev-area/file1; ls -l /data/dev-area/file1'
# 3) 새 파일의 그룹 확인
su - multiuser -c 'ls -l /data/dev-area/file1 | awk "{print \$4}"'
# 4) newgrp 로 유효 그룹 전환
su - multiuser -c 'id -gn; newgrp developers <<< "id -gn"'5. 실행 결과
텍스트 원본(실제 출력):
[root@rocky9-lab ~]# echo "=== multiuser 의 그룹 ==="
=== multiuser 의 그룹 ===
[root@rocky9-lab ~]# id multiuser
uid=1001(multiuser) gid=1003(multiuser) groups=1003(multiuser),1001(developers),1002(auditors)
[root@rocky9-lab ~]# echo "기본 그룹(gid=): $(id -gn multiuser) / 보조 그룹: $(id -Gn multiuser)"
기본 그룹(gid=): multiuser / 보조 그룹: multiuser developers auditors
[root@rocky9-lab ~]# echo "=== 보조 그룹 권한으로 접근 (재로그인 없이 newgrp) ==="
=== 보조 그룹 권한으로 접근 (재로그인 없이 newgrp) ===
[root@rocky9-lab ~]# su - multiuser -c 'touch /data/dev-area/file1 2>&1; ls -l /data/dev-area/file1'
-rw-r--r-- 1 multiuser developers 0 Sep 24 14:52 /data/dev-area/file1
[root@rocky9-lab ~]# echo "=== 새 파일의 그룹은? (SGID 디렉터리) ==="
=== 새 파일의 그룹은? (SGID 디렉터리) ===
[root@rocky9-lab ~]# su - multiuser -c 'ls -l /data/dev-area/file1 | awk "{print \$4}"'
developers
[root@rocky9-lab ~]# echo "=== 유효 그룹 전환 newgrp ==="
=== 유효 그룹 전환 newgrp ===
[root@rocky9-lab ~]# su - multiuser -c 'id -gn; newgrp developers <<< "id -gn"'
multiuser
developers6. 결과 해석
| 출력 | 해석 |
|---|---|
gid=1003(multiuser) groups=1003(multiuser),1001(developers),1002(auditors) | 기본 그룹 multiuser + 보조 developers·auditors |
기본 그룹: multiuser / 보조 그룹: multiuser developers auditors | id -gn(기본), id -Gn(전체) |
-rw-r--r-- multiuser developers file1 | SGID 디렉터리라 파일 그룹이 developers로 상속 |
ls ... awk → developers | 새 파일 그룹 확인 |
newgrp developers 후 id -gn → developers | 유효 그룹이 developers로 전환됨 |
SGID 디렉터리 덕분에 multiuser가 만든 파일이 기본 그룹(multiuser)이 아니라 developers 그룹을 가진 것이 핵심이다. 이것이 없었다면 파일 그룹은 multiuser가 되어 팀 공유가 깨졌을 것이다.
7. 보안 관점
| 주제 | 내용 |
|---|---|
| 최소 그룹 소속 | 보조 그룹이 많을수록 접근 범위가 넓다. 필요한 그룹만 |
| SGID 협업 | 공유는 SGID 디렉터리로. newgrp 의존은 실수 유발 |
| 유효 그룹 감사 | newgrp로 특권 그룹 전환은 드문 행위 |
| 파일 그룹 점검 | 공유 디렉터리에 개인 그룹 파일이 섞이면 접근 문제 |
과장 금지: 사용자가 여러 그룹에 속하는 것 자체는 정상이다. 문제는 불필요하게 특권 그룹(wheel·docker)에 속하는 것 이다. 그룹 소속 점검(34·48편)의 대상은 특권 그룹이다.
8. 보안관제 관점
| 관점 | 내용 |
|---|---|
| Investigation | 파일 그룹으로 "어느 팀/역할이 만들었는지" 추정. SGID 디렉터리면 디렉터리 그룹 기준 |
| Detection | newgrp로 특권 그룹 전환, 보조 그룹 변경(usermod/gpasswd)을 감시 |
| Baseline | 사용자별 그룹 소속을 기준값으로 관리(48편) |
| Evidence | 공유 디렉터리 파일의 소유자·그룹으로 협업 흐름 재구성 |
[점검] 사용자별 그룹 소속과 Baseline 비교
for u in $(awk -F: '$3>=1000{print $1}' /etc/passwd); do echo "$u: $(id -Gn $u)"; done
↓
[이상] 특권 그룹(wheel/docker/disk)에 예상 밖 계정
↓
[Evidence] /etc/group 변경 시각, gpasswd/usermod 로그
↓
[Response] 무단 소속 제거, 경위 조사9. 실무에서 자주 발생하는 실수
| 실수 | 결과 | 예방 |
|---|---|---|
| 공유 디렉터리에 SGID 미설정 | 파일 그룹 제각각 | chmod 2770/2775 |
| newgrp 의존 협업 | 매번 전환, 실수 | SGID 디렉터리 |
| 보조 그룹 남발 | 접근 범위 확대 | 최소 소속 |
| 기본 그룹을 공유 그룹으로 | 새 파일 그룹 혼란 | UPG + SGID 조합 |
id -gn과 id -Gn 혼동 | 그룹 파악 오류 | 기본/전체 구분 |
10. 실습 체크리스트
[ ] id 로 기본 그룹과 보조 그룹을 구분했다
[ ] 권한 검사는 전체 그룹, 새 파일 그룹은 기본 그룹임을 이해했다
[ ] SGID 디렉터리에서 새 파일이 그룹을 상속하는 것을 확인했다
[ ] newgrp 로 유효 그룹을 전환했다
[ ] 협업에 SGID 가 newgrp 보다 나은 이유를 설명할 수 있다
[ ] 특권 그룹 소속 점검의 필요성을 안다11. 핵심 정리
- 프로세스는 기본 그룹 1개(egid) + 보조 그룹 여러 개 를 가진다.
- 권한 검사는 전체 그룹으로, 새 파일 그룹은 기본 그룹 하나 로 정해진다.
- 이 비대칭 때문에 협업 디렉터리는 SGID 로 그룹 상속을 보장한다(29편).
newgrp로 유효 그룹을 전환할 수 있지만, SGID 디렉터리가 더 실용적이다.- 여러 그룹 소속은 정상이며, 점검 대상은 특권 그룹 소속이다.
12. 다음 편 예고
Part 4의 마지막 글 「40. root 계정과 시스템 계정」 에서는 UID 0(root)의 특별함, daemon·bin·nobody 같은 시스템 계정의 역할과 공통 특징(nologin 셸), 그리고 "UID 0은 root 하나뿐이어야 한다"는 핵심 점검을 정리한다.
참고 자료
- credentials(7) — Supplementary group IDs — https://man7.org/linux/man-pages/man7/credentials.7.html
- newgrp(1) — https://man7.org/linux/man-pages/man1/newgrp.1.html
- inode(7) — Set-group-ID and directories — https://man7.org/linux/man-pages/man7/inode.7.html
시리즈 이동
- [이전 글] 38. groupadd와 그룹 관리
- [현재 글] 39. 기본 그룹과 보조 그룹
- [다음 글] 40. root 계정과 시스템 계정
