단일 기본 프로세스에서만 원본 파일을 삭제할 수 있는 방법이 있습니까?
다른 프로세스에서는 이를 읽고 수정할 수 있지만 삭제할 수는 없습니다. 프로세스가 내용을 비울 수 있다는 것을 알고 있지만 이러한 프로세스는 인간 상호 작용을 통해 내용에 액세스하므로 이는 문제가 되지 않습니다.
핵심은 기본 프로세스가 inode에 대한 액세스를 잃어서는 안 된다는 것입니다. Ext4가 그런가요? 절대 경로에 관한 것이 아니라 인덱스 노드에 관한 것입니다. 그렇죠?
일부 프로세스에서는 안전한 쓰기를 제공하기 위해 새 파일을 쓰고 원본 파일을 삭제하거나 이름을 바꾼 다음 새 파일의 이름을 원본 파일로 바꾸고 원본 파일을 삭제하지만 이로 인해 원본 inode가 손실되고 기본 프로세스가 파일에 추가할 때 재생성을 시도하지 않습니다. (프로세스는 동일한 inode에서 새 콘텐츠를 백업, 비교 및 쓸 수 있지만 그렇지 않습니다.)
주요 프로세스는 어디에도 작성되지 않은 것으로 보입니다.
답변1
단일 기본 프로세스에서만 원본 파일을 삭제할 수 있는 방법이 있습니까?
습관. 파일 액세스는 각 프로세스가 아닌 사용자 ID 및 그룹 ID를 기준으로 이루어집니다.
물론 프로세스에 별도의 그룹 ID를 부여하거나 자체 사용자로 실행할 수 있습니다. 그러면 다른 프로세스와 마찬가지로 별도의 "범주"에 배치되고 별도의 권한을 정의할 수 있습니다.
이러한 프로세스는 인간의 상호 작용을 통해 액세스하므로 문제가 없습니다.
글쎄요, 그건 그리 논리적이지 않습니다. 대화형 프로세스는 비대화형 프로세스와 정확히 동일할 수 있으며 일반적으로 최소한 그만큼의 버그가 있습니다.)
일부 절차에서는 안전한 쓰기를 제공하기 위해 새 파일을 작성하고 원본 파일을 삭제하거나 이름을 바꾼 다음 새 파일을 원본 파일로 이름을 바꾸고 원본 파일을 삭제합니다.
아니요! 반대의 경우가 발생합니다. 새 파일에 쓰고 새 파일의 이름을 이전 파일의 이름으로 바꿉니다. 이는 원자적이므로 그렇게 하는 것입니다.오래된 파일은 절대 삭제되지 않습니다!프로세스의 매 순간마다 정확한 이름을 가진 파일이 있을 것입니다.
모든 파일 액세스에 대해 다음을 참고하세요.아무것하지만추가단일 write데이터의 경우 이 원자 교체가 유일한 안전한 방법입니다! (잠금 구조로 정말 특이한 작업을 수행하려는 경우가 아니라면 대부분의 파일 형식은 그러한 작업도 허용하지 않습니다!)
따라서 자신이 해결하고 있다고 생각하는 문제가 무엇이든 괜찮을 것입니다. 원하는 것을 달성하려면 다른 방법을 찾아야 합니다.
동일한 inode에 새 콘텐츠 쓰기
가끔은 "inode"라는 단어가 사라졌으면 좋겠어요! 이는 실제로 파일 시스템의 디스크 형식에 대한 구현 세부 사항일 뿐이며 사용자는 이를 사용해야 합니다.안 돼요 처리해야합니다. 사실입니다. 파일 시스템을 개발하지 않는 한, inode에 관심을 갖기 시작할 때 아마도 뭔가 잘못된 일을 하고 있을 것입니다.
답변2
"명백한" 대답은 "모호함을 통한 보안"(STO)입니다. 즉, 다른 프로세스가 이를 알지 못하도록 방지합니다. 이름파일.
이 질문에는 소프트웨어 아키텍처에 대한 맥락이나 큰 그림이 부족합니다. "주 프로세스"라는 용어를 사용하면 부모파일을 열고 파일 설명자를 전달하는 프로세스 어린이 프로세스. "다른 프로세스"가 독립적으로 파일을 여는 경우 파일 이름을 알아야 하며 이 방법을 사용할 수 없습니다. 마찬가지로, 파일 이름이 하드코딩되어 있고 "잘 알려진" 경우 이 접근 방식은 쓸모가 없습니다.
가변 파일 이름을 가진 상위/하위 아키텍처가 있는 경우 하위 프로세스에서 이름을 비밀로 유지하십시오.
가능한 찾다파일의 경우 해당 inode 번호를 알고 있는 경우. 공개적으로 읽을 수 없는 디렉터리에 파일을 배치하여 이 공격 경로를 차단할 수 있습니다.
답변3
다음을 수행할 수 있습니다.
먼저, 다른 모든 프로세스(기본 프로세스 제외)가 모든 유형의 파일에 쓸 수 없도록 비활성화합니다. 예를 들면 다음과 같습니다.
mv my_precious_file my_precious_file.original
둘째, 파일에 대한 하드 링크를 만듭니다.
sudo ln my_precious_file.original my_precious_file.copy
셋째, 신뢰할 수 없는 하위 프로세스가 하드 링크된 파일에 액세스하도록 허용합니다.
# DUMMY example, this is not code you shall execute,
# it's purpose is to show that a process might delete the original file,
# but now it can only delete the hard linked "copy" and not the "original"
# "Haha I'm a not trustworthly process." (Some people don't understand.)
cp my_precious_file.copy /dev/null && rm my_precious_file.copy
귀하의 하위 프로세스는 여전히 하드 링크의 "사본"을 삭제할 수 있지만 "원본"은 "변경되지 않은" 상태로 유지됩니다.
하드 링크의 "복사본"이 "삭제"된 경우 이를 "다시 생성"하면 됩니다.