BtrFS는 실제로 이것을 지원해야 합니다.하지만 그것은 진실이 아니다. 따라서 ECryptFS는 이러한 격차를 메울 것으로 보입니다. 유일한 질문은 이것 위에 압축을 어떻게 쌓을 수 있느냐는 것입니다.
암호화 외에 압축을 하는 이유:
- 의도적으로 반대 프로세스(압축에 따른 암호화)는 압축하지 않습니다. 이상적으로는 암호화가 암호문을 임의의 데이터와 구별할 수 없게 만들려고 시도하기 때문입니다.
- 밀도가 높은 정보 암호화가 더 안전합니다.
나는 임시적으로 파일을 다른 키(예: 사용자/그룹)로 암호화할 수 있도록(즉, 블록 수준 암호화와 같은 주요 재구성 없이 변경 가능) 파일 시스템 수준 솔루션을 찾고 있습니다.
답변1
이제 남은 유일한 방법은 암호화된 파일 시스템 위에 압축 파일 시스템을 쌓는 것뿐인 것 같습니다. 다음은 몇 가지 옵션이지만 실제 경험이 없습니다.
- 퓨즈 압축GitHub에서 호스팅됨
- SquashFS, JFFS2 또는 일부 조합LWN에 대한 설명
파일별로 압축 또는 암호화를 선택할 수 있는지 의심됩니다. Btrfs는 이를 제공할 수 있어야 하지만 현실은 이와 거리가 멀 수 있습니다. 마치 5년 전에 RAID가 있었어야 했던 것처럼요.
답변2
압축 파일 시스템이 encryptfs 위에 마운트될 때 실행되는 일부 데이터베이스 파일에 압축 파일 시스템의 입력(주로 슈퍼블록 개인 정보 필드)을 포함해야 합니다(마운트 시간 매개변수 전달에 -o 옵션 사용). 이는 파일 시스템 방법에 미리 정의된 일부 메커니즘에 따라 들어오는 파일 읽기/쓰기 요청에 대해 작동하는 스택형 파일 시스템이 될 것입니다.
일부 파일이 특정 알고리즘을 사용하여 압축된다고 가정하면 이는 압축fs/main.c 및 file.c 등에 작성할 읽기/쓰기 방법으로 계산되어야 합니다. 추가/제거/목록 알고리즘을 지원하기 위해 설치 중에 이식된 데이터베이스에 쓰는 것과 같이 이 압축 기능 파일 시스템을 업데이트하기 위해 ioctl을 구현하는 사용자 수준 코드를 작성합니다.