파일이 생성, 수정, 삭제, 복사 또는 이동된 후에 작업을 트리거하는 서비스가 필요합니다.

아이디어는 어떤 응용 프로그램이 foo를 생성했는지, 언제, 왜, 어디서, 언제 어디서 어디로 이동했는지, 언제 어디서 어디로 복사되었는지, 복사본 수, 어디에 있는지, 어떤 파일이 삭제되었는지 기록하는 것입니다. 디렉토리 등

• "어떤 응용 프로그램이 그것을 생성했는지 foo": 전통적으로 Unix 계열 시스템은 어떤 응용 프로그램만 추적했습니다.사용자파일을 소유하고(처음에는 파일을 생성한 동일한 사용자이지만 시스템 관리자의 조치로 이를 변경할 수 있음) 응용 프로그램은 그런 의미에서 사용자가 원하는 확장으로 간주됩니다.

• crtime"when [created]": 이를 위해서는 특정 Linux 파일 시스템에서 지원되는 것과 같이 생성 시간을 지원하는 파일 시스템이 필요합니다 . 모든 Unix 계열 파일 시스템에 세 가지 기본 타임스탬프 ctime(파일의 메타데이터가 마지막으로 변경된 시간, mtime= 파일의 내용이 마지막으로 수정된 시간, atime= 파일이 마지막으로 액세스된 시간)가 있는 것은 아닙니다. 이 세 가지와 달리 crtime사용자 공간 도구에서는 지원이 매우 제한적입니다.

• “왜 [만들어졌나요]”: 아, 목적론도 원하시나요? 이것은 어려운 질문입니다. 기본적으로 파일과 연결된 메타데이터 필드가 있어야 하며 모든 애플리케이션은 파일을 생성할 때 이 필드에 의미 있는 정보를 채워야 합니다. 운영 체제는 알 수 없습니다.왜애플리케이션은 어떤 방식으로든 그렇게 하라는 지시가 없는 한 특정 파일을 생성하려고 하며 애플리케이션이 알 수 있는 방법이 없습니다.왜사용자는 사용자에게 요청하지 않는 한 파일을 생성하려고 합니다. 하지만 "임시 파일", "응용 프로그램 구성 파일", "사용자 문서 파일" 등과 같은 광범위한 범주로 원할 수도 있습니다. 그렇더라도 이러한 움직임을 완전히 구현하려면 전체 운영 체제와 모든 애플리케이션을 업데이트해야 할 수도 있습니다.

• "where": 파일이 어디에 있는지 아는 것은 파일 시스템의 매우 기본적인 속성입니다. 하지만 일종의 감사 로그가 필요한 것 같습니다.

• "어디에서 어디로 움직일 때": 움직임은 움직임으로만 인식될 수 있다는 점에 유의하세요.단일 파일 시스템 내에서. 파일 시스템 간 이동은 본질적으로 복사+삭제 작업입니다. 운영 체제에 관한 한 이는 본질적으로 "파일 A에서 읽기, 파일 B에 쓰기, 파일 A 삭제"입니다. 이 작업을 수행하는 애플리케이션을 신뢰하고 해당 목적이 콘텐츠를 복사/이동하는 것임을 알지 않는 한, 애플리케이션은 운영 체제가 수정 사항을 인식하지 못한 채 읽기 및 쓰기 작업 사이에 어떤 방식으로든 데이터를 수정할 수 있습니다.

목표를 완전히 달성하려면 각 파일의 조상과 목적을 추적하기 위해 모든 관련 파일 관리 API를 다시 디자인한 완전히 새로운 운영 체제를 작성해야 할 것입니다.

이에 대해 진지하게 생각한다면 먼저 SELinux 및/또는 기타 필수 액세스 제어 시스템을 살펴보고 이해하는 것이 좋습니다.벨-라파두라 모델. 이는 파일의 조상 및 목적이 아닌 파일의 보안 상태를 추적하기 위한 것이지만 이러한 추적을 구현하는 방법에 대한 몇 가지 아이디어를 얻을 수 있습니다.