설치 전에 재는 uid

호스트에 명령줄 도구를 몇 개 깔려고 했는데 컨테이너에 들어가 명령을 치는 것이 번거로웠기 때문이다. 깔기 전에 위험 평가를 했고 그 평가가 실제로 필요했다.

Open Table of contents

겹치는 데이터 디렉터리

컨테이너 몇 개가 호스트의 디렉터리를 직접 마운트해서 데이터 저장에 쓰고 있었다. 호스트에 같은 패키지를 깔면 그 패키지도 관례상 같은 경로를 데이터 디렉터리로 잡는다.

배포판이 달라도 이런 경로는 대체로 같기 때문에 겹칠 가능성이 높았다. 겹치는 경로를 두 주체가 서로 모른 채로 쓰는 것이 이 상황의 위험이었다.

패키지를 깔면 서비스 사용자가 만들어지고 그 사용자가 데이터 디렉터리를 소유하게 된다. 지금 상태를 보니 그 번호를 시스템 데몬이 이미 점유하고 있었다.

컨테이너 안에서 도는 프로세스도 같은 번호였고 디렉터리 소유자도 그 번호에 권한이 좁게 걸려 있었다. 세 곳이 같은 식별자에 물려 있는 상태였다.

패키지가 사용자를 만들려 할 때 그 번호가 차 있으면 다른 번호를 받게 된다. 설치 과정에서 데이터 디렉터리를 새 사용자 소유로 바꾸면 컨테이너 프로세스가 자기 데이터에 접근을 잃는다.

권한이 좁게 걸려 있어서 그룹이나 기타 사용자로는 읽지도 못하므로 컨테이너가 다음 쓰기 시점에 죽는다. 설치 직후가 아니라 나중에 죽는다는 점이 이 사고를 찾기 어렵게 만든다.

실제로 깔고 나서 다시 보니 소유권이 그대로였고 서비스 사용자도 안 만들어졌으며 서비스는 비활성 상태였다. 디렉터리가 이미 있고 번호가 차 있어서 설치 스크립트가 넘어간 것으로 보인다.

그렇다고 안 건드렸으니 괜찮다로 끝내지 않고 컨테이너에 직접 요청을 보내 응답을 확인했다. 파일 상태가 안 바뀐 것과 프로세스가 정상인 것은 다른 사실이라 둘 다 봐야 했다.

이번에는 괜찮았지만 다른 패키지였으면 소유권 변경이 돌았을 수도 있다. 그래서 호스트에는 클라이언트만 두고 서버는 기동하지 않는다는 원칙을 정했다.

서버가 뜨면 같은 데이터 디렉터리를 두 프로세스가 쓰게 되어 확실히 깨진다. 패키지가 없는 도구는 실행 파일을 직접 풀거나 인터페이스를 직접 호출하는 것으로 대체했는데 목적이 도구 설치가 아니라 호스트에서 명령을 치는 것이었기 때문이다.