LFCS 사용자·그룹·SGID 핵심 정리
사용자, 기본·보조 그룹, 디렉터리 권한과 SGID의 동작을 명령 예시로 정리
이 문서는 local user·group의 기초 층이다. 환경 profile·limits·ACL·LDAP는 고급 개념에서 이어진다.
작성·검증 상태: AI가 구조화와 설명 초안을 보조했다. 계정·group·permission 명령은 GNU/Linux의 일반 동작을 설명하며, UID·GID 정책과 기본값은 현재 배포판 설정을 우선한다.
이 영역을 끝내는 순서
- 이 문서에서 account·primary/supplementary group·directory permission·SGID·umask를 구분한다.
- 기본 안내형 lab에서 공유 directory를 직접 구성한다.
- 고급 개념과 고급 lab에서 공식 나머지 네 항목을 수행한다.
- 영문 단계별 실전을 풀이 없이 두 번 완료한다.
완료 기준은 getent·id·stat 같은 상태 조회뿐 아니라 실제 user의 file 생성·읽기·쓰기와 새 login session에서의 적용을 확인하는 것이다.
공식 Users and Groups 영역 중 local user·group account의 기초를 다룬다. environment profile, resource limit, ACL, LDAP는 시험 범위 체크리스트에서 별도로 확인한다.
SGID는 공식 competency 이름에는 없지만 local user/group와 공유 디렉터리 권한의 상호작용을 이해하는 데 유용하다.
사용자와 그룹의 최소 모델
프로세스의 파일 접근 판단에는 숫자 ID가 사용된다.
- 사용자: 이름과 UID
- 기본 그룹: 사용자마다 하나의 primary GID
- 보조 그룹: 사용자가 추가로 속한 supplementary group 목록
주요 로컬 데이터는 다음 파일에 저장되지만, 조회할 때는 파일을 직접 검색하기보다 NSS를 거치는 getent와 id를 먼저 사용한다.
| 파일 | 역할 |
|---|---|
/etc/passwd | 사용자명, UID, 기본 GID, 홈, 로그인 셸 |
/etc/shadow | 비밀번호 해시와 만료 정책 |
/etc/group | 그룹명, GID, 명시된 멤버 |
/etc/gshadow | 그룹 관리·인증 정보 |
getent passwd lfcsuser
getent group devops
id lfcsuser/etc/group의 멤버 목록만 보면 사용자의 기본 그룹 관계가 보이지 않을 수 있다. 최종 소속을 볼 때는 id username을 함께 확인한다.
생성과 수정을 구분한다
다음 계정 변경 명령은 root 권한으로 실행하는 예시다.
# 새 그룹과 새 사용자
groupadd devops
useradd -m -s /bin/bash lfcsuser
# 기존 사용자의 보조 그룹에 devops 추가
usermod -aG devops lfcsuseruseradd는 새 사용자를 만들고 usermod는 기존 사용자를 바꾼다. 이미 있는 사용자를 그룹에 넣기 위해 삭제 후 재생성하지 않는다.
usermod -G가 위험한 이유
usermod -G devops lfcsuser-G는 보조 그룹 목록을 새로 지정한다. 명령에 적지 않은 기존 보조 그룹에서 사용자가 빠질 수 있다. 기존 목록을 유지하면서 추가하려면 -aG를 사용한다.
변경 전후를 비교하면 부수 효과를 확인할 수 있다.
id lfcsuser
usermod -aG devops lfcsuser
id lfcsuser디렉터리 접근 권한
디렉터리에서 권한의 의미는 일반 파일과 다르다.
| 권한 | 디렉터리에서의 의미 |
|---|---|
r | 항목 이름 목록을 읽음 |
w | x와 함께 디렉터리 항목을 생성·삭제·이름 변경 |
x | 경로를 통과하고 항목에 접근 |
공유 디렉터리를 root:devops, 2770으로 만들면 다음 상태가 된다.
chown root:devops /srv/project
chmod 2770 /srv/projectdrwxrws--- root devops /srv/project- 소유자
root:rwx - 그룹
devops:rwx - 기타 사용자: 접근 불가
- 앞자리
2: SGID
디렉터리에 SGID가 설정되면 새 항목의 그룹 ID는 생성 프로세스의 effective GID가 아니라 부모 디렉터리의 그룹 ID를 따른다. 새 하위 디렉터리에는 SGID 비트도 설정된다.
SGID는 파일의 읽기·쓰기 권한을 자동 상속하지 않는다. default ACL이 없으면 프로그램이 요청한 생성 모드에서 umask가 권한을 제한한다. default ACL이 있으면 그 ACL을 상속한 뒤 프로그램이 요청한 생성 모드에 없는 권한을 제거하며, 이 경로에서는 umask를 별도로 적용하지 않는다.
검증은 설정값에서 끝내지 않는다
1. 상태
id lfcsuser
getent group devops
stat -c '%A %a %U:%G %n' /srv/project2. 동작
devops에 속한 사용자로 실제 파일과 디렉터리를 만들고 그룹 소유권을 확인한다.
runuser -u lfcsuser -- bash -c \
'umask 0002; touch /srv/project/from-lfcsuser; mkdir /srv/project/child'
stat -c '%A %a %U:%G %n' \
/srv/project/from-lfcsuser \
/srv/project/child확인할 것은 다음과 같다.
lfcsuser가/srv/project안에 항목을 만들 수 있는가?- 생성된 항목의 그룹이
devops인가? - 하위 디렉터리에 SGID가 설정됐는가?
- 파일의 그룹 쓰기 권한이
umask예상과 맞는가?
3. 새 세션
이미 로그인한 셸은 변경된 보조 그룹 목록을 자동으로 반영하지 않는다. 조회 대상을 구분한다.
id # 이 명령을 실행한 현재 프로세스의 그룹
id lfcsuser # NSS가 반환한 lfcsuser의 현재 계정 정보
runuser -u lfcsuser -- id # root가 새 프로세스로 초기화한 lfcsuser의 그룹lfcsuser에 비밀번호나 SSH 키를 설정하지 않았다면 그 계정으로 새 SSH 로그인을 요구하지 않는다. 이 실습은 root 셸에서 runuser로 새 프로세스를 시작해 반영 여부를 확인한다. newgrp로 현재 셸의 그룹 상태를 바꾸는 것과 새 프로세스에서 계정 상태를 확인하는 것도 구분한다.
안전한 풀이 순서
getent,id,stat로 초기 상태를 확인한다.- 새 객체는
groupadd,useradd로 만든다. - 기존 사용자 변경은
usermod -aG처럼 부수 효과가 적은 명령을 고른다. chown과chmod로 요구된 최종 상태를 만든다.- 상태, 실제 동작, 새 세션을 검증한다.
- 요구하지 않은 사용자 삭제, 재생성, 재귀 권한 변경은 하지 않는다.
스스로 설명할 질문
- 기본 그룹과 보조 그룹은 어떻게 다른가?
usermod -G와usermod -aG의 결과는 어떻게 다른가?- 디렉터리에
x가 없으면r이 있어도 무엇을 할 수 없는가? 2770의 첫 번째 숫자2는 어떤 동작을 만드는가?- SGID와
umask는 새 파일의 그룹과 권한에 각각 어떤 영향을 주는가?
답을 설명한 뒤 Users & Groups 실습을 풀이를 펼치지 않고 수행한다.