사용자와 그룹

실행 주체가 장애의 범위를 결정합니다

작은 운영 실습실에서 설정을 읽고 데이터를 저장하는 웹 앱을 돌릴 예정입니다. 작업자가 파일을 준비하는 권한과 앱이 실행 중 필요한 권한을 한 계정에 몰아주면 앱의 실수도 작업자의 변경 권한으로 수행됩니다. 이번 레슨은 계정을 늘리는 연습보다 누가 어느 작업을 해야 하는지 경계를 만드는 연습입니다. 서비스에는 데이터 저장 권한이 필요하지만 계정 생성이나 설정 교체 권한은 필요하지 않습니다.

이 모듈의 VM 과제는 앞 모듈의 Linux systemd 실습 VM에서 진행합니다. Bash·Python 3·shadow-utils·coreutils·sudo가 필요합니다. 기존 VM 관리자 콘솔을 유지하고 스냅샷을 준비합니다. 서비스 계정 생성과 다른 UID 접근 검사는 external이며 이 맥에서 실행하지 않았습니다. ZIP 안 README의 준비 순서를 따르고, 검사 명령의 실패를 감추거나 계정에 sudo 그룹을 추가해 통과시키지 않습니다.

계정 이름은 작업자 bcops, 서비스 bcweb, 공유 그룹 bcapp으로 고정합니다. 이 이름이 이미 있으면 setup.sh가 중단합니다. 기존 계정의 용도를 추측해 수정하지 말고 새 실습 VM을 사용합니다. 관리자 작업은 계정·그룹 생성과 /srv/bootcamp-m02 경로 준비에 한정합니다. 실습 뒤에는 임의의 userdel 명령보다 준비 전 스냅샷으로 돌아가 계정과 파일의 상태를 함께 복구합니다.

이름과 숫자를 나눠 관측합니다

사용자 이름은 사람이 읽는 식별자이며 UID는 파일 소유권과 프로세스 자격을 연결하는 숫자입니다. 다른 이름을 붙였어도 같은 UID를 쓰면 권한 분리를 기대하기 어렵습니다. id bcops와 id bcweb로 각각 UID를 확인하고 서로 다르며 0이 아닌지 대조합니다. UID 0은 일반 서비스 실행 주체로 적합하지 않습니다. UID가 얼마일지는 VM마다 달라 예제 숫자를 정답으로 고정하지 않습니다.

GID는 그룹의 숫자 식별자입니다. 기본 그룹은 계정의 초기 그룹 자격이며 보조 그룹은 추가 접근 범위를 제공합니다. bcweb의 기본 그룹을 bcapp으로 두고 bcops를 bcapp 보조 그룹에 넣으면 두 계정이 같은 설정을 읽을 수 있는 기반을 만듭니다. 그룹에 속한다는 사실만으로 파일 쓰기를 허용한 것은 아닙니다. 다음 레슨에서 실제 경로의 그룹 모드와 함께 판단합니다.

getent passwd bcweb는 이름 서비스가 조회한 계정 레코드를 보여 줍니다. 콜론으로 구분된 항목에는 이름·UID·GID·홈 경로·로그인 셸이 들어 있습니다. 비밀번호 자리에 보이는 x를 비밀번호 그 자체로 해석하지 않습니다. /etc/shadow를 출력하거나 증거에 복사할 이유가 없습니다. 서비스 UID와 홈·셸·그룹만 남겨도 이번 검증에 필요한 실행 주체를 설명할 수 있습니다.

로그인 계정과 서비스 계정의 차이

bcops에는 /bin/bash와 홈 디렉터리를 지정해 사람의 작업 공간을 마련합니다. setup.sh는 비밀번호를 설정하지 않으므로 계정 생성 직후 비밀번호 로그인까지 완료된 것으로 적지 않습니다. 이번 실습에서는 기존 VM 관리자가 sudo -u bcops로 작업 주체를 선택합니다. 로그인 가능 셸을 갖는 것과 인증 수단이 준비된 것은 서로 다른 조건입니다. 별도의 SSH 키 설치는 뒤 모듈에서 다룹니다.

bcweb는 홈을 만들지 않고 실행용 경로를 홈 필드에 적으며 nologin 셸을 사용합니다. nologin의 실제 설치 위치는 command -v nologin으로 찾아 파일 존재를 확인합니다. 특정 배포판의 경로를 모든 Linux에 고정하지 않습니다. -r 옵션이 선택하는 시스템 UID 범위 역시 배포판 설정에 영향을 받으므로 999 같은 숫자를 목표로 삼지 않습니다.

로그인 셸을 nologin으로 바꿨다고 그 UID로 실행되는 프로세스까지 금지되는 것은 아닙니다. 관리자나 서비스 관리자는 허가된 명령을 해당 UID로 직접 실행할 수 있습니다. 따라서 sudo -u bcweb id는 서비스 자격 확인에 사용할 수 있습니다. 반대로 앱이 실행되는 동안 파일을 어디까지 읽고 쓰는지는 셸 값이 아니라 UID·그룹·경로 권한으로 따로 제한합니다.

생성과 확인을 별도 단계로 수행합니다

다운로드한 실습의 setup.sh를 읽고 고정 경로와 생성 이름을 확인한 뒤 Linux VM에서 sudo bash setup.sh를 한 번 실행합니다. 이 스크립트는 기존 sudoers를 수정하지 않습니다. 준비 뒤에는 일반 사용자로 task.sh에서 계정 증거를 수집합니다. 계정 DB 변경은 관리자 작업, 조회 결과를 자기 evidence에 기록하는 것은 일반 사용자 작업으로 구분합니다.

check.sh는 두 UID가 다른지, 서비스의 기본 GID가 bcapp인지, 작업자가 공유 그룹에 포함되는지, 홈과 셸이 의도대로인지 확인합니다. evidence/passwd.txt와 identities.md에는 조회 결과와 역할을 연결해 적습니다. 단순히 명령이 종료 코드 0을 냈다는 기록보다 UID·GID·셸이 어느 요구를 충족하는지 설명한 기록이 인계에 유용합니다.

그룹을 나중에 추가할 때 usermod -aG는 기존 보조 그룹을 보존하며 추가합니다. -G만 사용하면 기존 보조 그룹 목록을 교체할 수 있습니다. 이번 준비는 생성 시점에 그룹을 지정하지만 인계된 VM에서는 먼저 현재 그룹을 읽어야 합니다. 이미 실행 중인 셸이나 프로세스의 보조 그룹은 계정 DB 변경만으로 자동 갱신되지 않으므로 새 세션에서 실제 id 결과도 확인합니다.

오류를 계정 설정의 문제로 좁힙니다

이미 있는 계정이라는 준비 오류는 이름 충돌입니다. 기존 계정을 지우거나 셸을 강제로 바꾸기 전에 새 VM 조건을 확인합니다. useradd에서 Permission denied가 나오면 계정 DB를 바꿀 관리자 자격과 실행 환경을 확인합니다. getent가 결과 없이 종료하면 이름 철자나 계정 생성 완료 여부를 점검합니다. 로그인 오류와 파일 접근 오류를 한 원인으로 합치지 않습니다.

서비스 계정으로 로그인 시도할 때 나오는 계정 사용 불가 메시지는 nologin의 의도된 결과일 수 있습니다. 앱이 설정을 읽지 못한다는 장애를 해결하려고 로그인 셸을 bash로 바꾸는 조치는 접근 권한 문제를 해결하지 못합니다. 이번 레슨의 제출물은 역할표·계정 조회·셸 확인입니다. 계정 생성 옵션의 전체 목록은 더 읽기에 연결하며, 다음 레슨에서는 이 계정으로 파일 접근을 검증합니다.

계정 생성 옵션 기준: shadow-utils useradd(8).