관리자 권한의 경계

관리자는 준비하고 서비스는 실행합니다

실습 웹 앱이 데이터를 쓰지 못할 때 root로 실행하면 증상이 사라질 수 있습니다. 그러나 그 결과는 서비스에 필요한 범위를 확인한 증거가 아닙니다. 이 레슨에서는 관리자 권한이 필요한 계정 생성·소유권 변경과 일반 주체로 가능한 읽기·데이터 저장·증거 기록을 분리합니다. 목표는 sudo 명령 횟수 줄이기가 아니라 변경 범위와 실행 자격을 설명하는 권한표를 만드는 것입니다.

기존 VM 관리자 계정은 실습 준비와 검사 시의 주체 전환을 수행합니다. bcops와 bcweb에 새 sudo 권한을 부여하지 않습니다. task.sh는 본인의 evidence에 권한표를 만들고 sudo -u bcweb로 실제 서비스 읽기를 확인합니다. 서비스가 sudo를 사용해서 설정을 읽게 구현하지 않습니다. 검사자가 접근 결과를 재현하기 위해 다른 주체로 명령을 실행하는 것과 서비스에 관리 권한을 위임하는 것은 다릅니다.

sudo의 대상 주체를 명시합니다

sudo는 정책이 허용하는 범위에서 지정한 사용자로 명령을 실행합니다. -u bcweb는 root 대신 서비스 UID로 실행하겠다는 선택입니다. nologin 계정이어도 직접 지정한 실행 파일을 해당 UID로 실행할 수 있습니다. 파일 접근 실험에서는 id -u를 먼저 확인해 서비스로 실행한 결과인지 증명합니다. root로 cat이 성공했다는 관측은 bcweb의 읽기 권한을 보증하지 않습니다.

sudo -l은 현재 사용자의 허용 정책을 조회할 때 사용합니다. 배포판의 그룹 이름만 보고 권한을 단정하지 않고 실제 정책을 살펴봅니다. 이번 자동 검사는 bcweb의 그룹을 bcapp 하나로 제한하는지 확인하지만 전체 sudo 정책의 부재까지 보증하지는 않습니다. 별도 사용자 규칙이나 다른 정책 공급자의 위임이 있는지는 관리자 검토로 확인해야 합니다.

sudo는 계정 생성이나 chown처럼 일반 사용자가 수행할 수 없는 준비에 사용합니다. 자기 작업 폴더에 evidence를 만들거나 관측 텍스트를 쓰는 작업에는 필요하지 않습니다. 모든 작업을 sudo로 감싸면 증거 파일까지 root 소유가 돼 다음 일반 사용자 작업을 막을 수 있습니다. 권한이 필요해진 순간에 대상·명령·사유를 고르고 기록합니다.

리다이렉션의 주체를 확인합니다

sudo echo 내용을 파일로 보내는 표기는 echo만 다른 주체로 실행하고 파일 열기는 원래 셸이 수행합니다. 따라서 쓰기 권한이 없는 파일에 리다이렉션하면 echo의 권한을 올려도 실패할 수 있습니다. 서비스 쓰기 검사를 할 때는 sudo -u bcweb bash -c 안에서 리다이렉션을 수행해 파일 여는 주체까지 bcweb가 되도록 합니다.

bash -c 안에 외부 경로 문자열을 직접 이어 붙이지 않습니다. 명령 문자열은 고정하고 별도 위치 인자로 전달해 $1로 받습니다. 공백이 있는 경로와 따옴표가 명령 구조를 바꾸지 않도록 변수를 인용합니다. 예제의 _는 bash -c에서 $0 자리에 넣는 이름이며 그 뒤 인자가 $1입니다. 잘못된 인자 순서로 빈 경로에 쓰는 오류를 줄이는 데 도움이 됩니다.

관리자 소유 설정을 실제로 설치해야 하는 경우에는 검토된 원본을 install -m으로 고정 경로에 설치하고 소유자·그룹을 지정할 수 있습니다. 미션에서 accounts.md를 보존할 때도 이 방식으로 모드와 주체를 함께 정합니다. 설치할 문서 내용과 목적지는 먼저 일반 사용자 영역에서 확인합니다. 이번 단계에서는 임의의 운영 설정이나 /etc 전체를 변경하지 않습니다.

권한표는 명령이 아니라 책임을 기록합니다

privileges.txt는 작업 이름|실행 계정|사유 형식의 다섯 줄입니다. account-creation과 config-install은 root, config-read와 data-write는 bcweb, report-write는 bcops로 지정합니다. 이유 칸에는 계정 DB 변경, 다른 소유자 지정, 기동 설정 읽기, 런타임 자료 저장, 인계 작성처럼 구체적 목적을 적습니다. 같은 명령 이름도 대상과 작업에 따라 필요한 권한이 달라집니다.

check.sh는 행 수와 작업별 계정, 사유 존재, 실제 서비스 UID와 설정 읽기를 확인합니다. 사유가 적절한지는 사람이 명령과 경로를 대조합니다. 권한표를 통과했다고 아무 사용자에게나 sudo를 허용해도 되는 것은 아닙니다. 문서 필드 검사와 정책 검토를 분리해 기록하면 자동 검사 결과를 과장하지 않고 인계할 수 있습니다.

위임이 필요한 운영 환경에서는 실행 경로·인자·대상 사용자와 실행 파일을 수정할 수 있는 주체까지 검토합니다. 셸이나 Python 같은 범용 실행 도구를 root로 자유롭게 허용하면 안에서 다른 작업도 실행할 수 있습니다. 이번 과제는 sudoers를 수정하는 대신 기존 관리자의 허가된 검사만 사용합니다. 정책 편집 절차와 문법 확인은 더 읽기로 이어갑니다.

인증 실패와 접근 거부를 구분합니다

sudo가 인증 오류나 사용 불가를 반환하면 접근 거부 검증 전에 멈춰야 합니다. 서비스 UID 확인과 설정 읽기 성공을 먼저 확인하지 않은 채 부정 테스트의 비정상 종료만 모으면 모든 명령이 실행되지 않은 상황도 통과처럼 보입니다. check.sh는 sudo -v로 관리자 인증을 확인한 다음 실제 실행 UID를 대조합니다. 비밀번호는 입력 프롬프트에만 넣고 파일로 저장하지 않습니다.

Permission denied가 evidence 파일에서 발생하면 이전에 root로 생성했는지 소유자를 확인합니다. 쓰기 대상이 본인 실습 폴더인지도 확인하고 VM 스냅샷 또는 원본 ZIP을 기준으로 복구합니다. sudoers를 열어 모든 명령을 허용하는 조치는 이번 요구에 포함되지 않습니다. 그룹 이름이 맞다는 관측과 실제 실행이 허가된다는 관측은 서로 대체할 수 없습니다.

미션에서는 앞 모듈의 증거를 유지하며 계정·그룹·경로·권한·관리자 작업 사유를 accounts.md에 남깁니다. config 디렉터리에 쓰기를 주지 않아 설정 교체도 막고, data에는 서비스 생성 권한을 줍니다. 마지막 확인은 무엇이 성공했고 무엇이 실패했는지 나란히 기록하는 것입니다. 이 자료가 다음 프로세스·서비스 관리 모듈에서 실행 계정 선택의 근거가 됩니다.