키 앞에서 각 디렉터리의 검색 권한 확인

0600 모드와 올바른 소유자만으로는 서비스가 키를 열 수 있다고 보장할 수 없습니다. 빠진 권한은 보통 그 위의 디렉터리에 있습니다. 리눅스는 경로를 한 번에 한 구성 요소씩 해석하며, 각 단계는 다음 시도 전에 검색 권한이 필요합니다. 목록의 마지막 줄이 아니라 전체 경로를 읽으세요.

읽기 권한은 마지막 단계이지 유일한 단계가 아닙니다

파일을 열려면 커널이 루트나 작업 디렉터리에서 경로의 모든 구성 요소를 지나야 합니다. 검색 권한이 없는 디렉터리는 그 이동을 권한 오류로 멈춥니다. 파일 자체의 모드는 결코 조회되지 않으므로 완전히 읽을 수 있는 키가 읽을 수 없는 것처럼 보입니다. 오류는 대개 열 때 디렉터리 이름 없이 발생하므로 마지막 파일이 의심받습니다.

디렉터리에서 실행 비트는 실행이 아니라 검색을 뜻합니다. 키는 데이터로 남고, 이 수리의 어느 부분도 키를 실행 가능으로 표시할 것을 요구하지 않습니다.

서비스 계정으로 경로를 따라가세요

각 구성 요소를 소유자와 모드와 함께 나열하고, 그다음 실제 서비스 신원으로 읽기를 반복하세요. 셸과 데몬의 차이가 종종 답 전체입니다. 검사되는 것은 해석된 경로이므로 심볼릭 링크는 실제 대상까지 따라가세요.

namei -l /etc/openvpn/client/office.key
sudo -u vpn-reader stat -c '%A %U:%G %n' /etc/openvpn/client/office.key

서비스는 파일을 여러 단계에서 열기도 합니다. 일부 자료는 특권 설정 중에 읽히고, 다른 파일은 특권이 내려간 뒤에 열립니다. 파일을 읽는 루트 셸은 이후 워커의 접근을 재현하지 못합니다. 마운트 네임스페이스는 특히 컨테이너 안에서 같은 경로의 다른 보기를 제시할 수 있으므로 데몬의 파일 시스템 보기를 자신의 것과 비교하세요.

가장 좁은 적절한 권한을 변경하세요

프로세스에 접근을 주는 가장 작은 구성, 곧 필요한 디렉터리에 검색 권한이 있는 통제된 그룹, 서비스가 이미 소유한 관리된 위치, 또는 다른 문서화된 메커니즘을 고르세요. 파일을 읽는 데 그 디렉터리의 쓰기 권한은 필요하지 않습니다. 특권 구성에 대한 넓은 그룹 쓰기 권한은 정상적인 탐색 수리가 아닙니다. 재귀적 0777도 해결책이 아닙니다.

어느 구성 요소를 왜 바꿨는지 기록하세요. 이유가 기록되지 않은 권한 변경은 검토하기 어렵고 잊히기 쉽습니다.

모드 너머는 탐색 후에만 보세요

모드 비트가 충분해 보인다면 남은 점검은 ACL, 보안 정책, 샌드박스 제한입니다. ACL은 모드 비트가 없다고 암시하는 접근을 허용하거나, 허용하는 것처럼 보이는 접근을 거부할 수 있습니다. 그 설정은 기존 구성 소유자의 것이며, 끄는 대신 좁게 조정해야 합니다. 루트나 작업 디렉터리의 차이도 한 문맥에서는 되고 다른 문맥에서는 실패하는 절대 경로를 설명할 수 있습니다.

접근을 고치는 동안 파일이 무엇인지 놓치지 마세요. CA 인증서는 설계상 공개이고 개인 키는 아닙니다. 클라이언트가 다시 쓰는 파일은 읽기 전용 신원 키와 다른 쓰기 권한도 필요합니다. 비밀을 출력하지 않고 메타데이터를 검사하고, 변경 후 서비스 자체가 동작하는지 확인하세요. 서비스 문서에 짧은 메모를 남기면 다음 사람이 같은 탐색을 하지 않아도 됩니다.