허용된 답변을 바탕으로여기, 파일로 연결되는 디렉터리에서 액세스 확인을 수행하지 않기 때문입니다. 예를 들어, 로 전화하세요 openinode(inode #, flags).
내 질문은 간단합니다. 파일 자체에 필요한 액세스 제어 목록(선행 디렉터리 없이)이 이미 없는 이유는 무엇입니까?
이러한 주요 디렉터리(아마도 다른 권한이 있음)가 중요해지는 상황이 있습니까?
답변1
임의 개수의 하위 디렉터리, 파일, 하위 하위 디렉터리 등을 포함하는 디렉터리 구조가 있다고 가정해 보겠습니다. 특정 사용자 및 그룹을 제외한 모든 사용자의 액세스를 제거하고 싶습니다. 이것은 쉽습니다:
chown chosen_user:chosen_group some-directory
chmod ug=rwx,o-rwx some-directory
각 파일이 메타데이터에 액세스 제어를 포함하도록 제안한 접근 방식에 따라 이 작업을 수행해야 합니다(또는 setuid 바이너리와 같이 사용자/그룹을 직접 변경할 수 없는 경우 다른 ACL을 수행해야 합니다).각 파일마다. 왜 그걸 원하는 사람이 있겠습니까?
답변2
위의 이유 외에도무루의 대답, 나는 이것이 POSIX/UNIX 권한 있는 시스템에 대해 실행되고 보안 취약점으로 이어질 것임을 지적하고 싶습니다.
POSIX의 파일은 이름과 경로로 저장, 검색, 수정되고 속성과 권한이 확인됩니다. 파일의 기본 모델은 다음과 같습니다. 얻고자 하는 데이터 조각을 설명하는 문자열을 운영 체제에 제공합니다. 이는 이를 얻기 위해 통과해야 하는 디렉터리 계층 구조를 의미하며, 가능한지 확인하고 정상이면 다음과 같은 정보를 제공합니다. , 데이터 블록은 파일 설명자의 형태로 액세스됩니다.
위에서 언급한 것처럼 운영 체제에 파일을 "열기"를 요청하는 시점인 액세스 권한 확인이 발생하는 잘 정의된 시점이 있습니다.
동일한 권한 확인 프로세스를 거치지 않고 다른 식별자(inode 번호일 필요는 없음)를 도입하는 것은 여러 수준에서 보안 실수입니다!
경로 기반 액세스 제어 우회: 액세스해야 하는 경로는 파일을 열 수 있는 권한을 제한합니다. 바인드 마운트, 하드 링크, NFS 등을 사용하여 단일 파일을 여는 방법에는 여러 가지가 있을 수 있습니다. 이로 인해 파일에 액세스할 수 있는(또는 액세스할 수 없는) 권한이 달라질 수 있습니다. UNIX에서는 다음과 같이 말합니다. 파일에 대한 특정 작업을 수행할 수 있는 권한은 파일의 파일 시스템 항목에 저장된 속성이 아닙니다. inode 기반 액세스 방식은 이 제한을 비활성화하므로 우회할 수 있습니다.많은보안.
변경 사항: 인덱스 노드가 변경되지 않은 상태로 유지된다는 보장은 전혀 없습니다. 전혀 계약의 일부가 아닙니다.
더 나쁜 경우: 악용(예: 정기적으로 닫히거나 이름이 바뀌거나 다시 열리는 액세스 로그)을 읽고 싶습니다. 경로에 할 수 없다고 되어 있기 때문에 할 수 없습니다(예를 들어 파일이 644이더라도 권한이 없는 사용자는 /var/log/daemon/을 읽거나 실행할 수 없습니다). 올바르게 보이는 아이노드를 열 때까지 모든 아이노드를 무차별 대입합니다. 짜잔.
inode는 구현 세부 사항입니다. 원래 UNIX 파일 시스템에는 이러한 기능이 있었지만 중단되었습니다. inode nr이 다른/최신 파일 시스템에 "유용하다"고 가정할 이유가 없습니다. 사실, 내 추측으로는 순수 개수 관점에서 볼 때 Linux 커널이 지원하는 모든 파일 시스템 중에서 가장아니요Inode 번호는 전혀 저장되지 않지만 커널에 의해 "시뮬레이트"됩니다.