嘿，这个需求挺贴合离线设备的安全场景啊——要做一个只能用设备上的RSA公钥加密写入，就算设备被偷走，攻击者也没法解密内容，只有拿到对应的私钥才能解锁的文件系统对吧？你提到eCryptFS不支持这种单向场景，我给你梳理几个靠谱的实现思路：

1. 用RSA+对称加密混合方案，自己封装读写逻辑 #

因为RSA本身没法直接加密大文件（效率低且有长度限制），所以混合加密是必选的：

• 写入流程：每次要写文件时，先随机生成一个一次性的对称密钥（比如用AES-256-GCM，带自动验签防篡改），用这个对称密钥加密文件内容；再用设备上的RSA公钥加密这个对称密钥；最后把加密后的对称密钥和加密后的文件内容存在一起（比如把密钥存在文件头部，或者单独存一个同名的.key文件）。
• 读取限制：设备上只有RSA公钥，没法解密出对称密钥，自然就没法解密文件内容——你甚至可以直接屏蔽读取操作，比如写个小脚本，只允许执行写入相关的命令，读取直接报错。
• 优势：零依赖复杂的文件系统工具，适合离线设备；缺点是需要自己封装读写逻辑，没法直接用系统原生的cp、echo这类命令，得用你写的脚本操作。

2. 基于FUSE定制单向加密文件系统 #

FUSE允许你在用户态开发自己的文件系统，刚好能满足这种定制化的需求：

• 核心逻辑：在文件系统的写入回调里实现上面的混合加密流程，把加密后的内容存在底层存储；而读取回调直接返回权限错误（比如EPERM），彻底禁止设备上的读取操作。
• 实现简化：不用从零写libfuse代码，用Python的fusepy或者Go的bazil.org/fuse这类封装库，几行代码就能搭起框架，然后把加密逻辑塞进去就行。
• 优势：用户体验好，挂载后就像用普通文件夹一样，直接用系统命令写入，读取会被自动拦截；缺点是需要写少量代码，不过难度很低，适合有基础的开发者。

为什么eCryptFS不适合这个场景？ #

eCryptFS的设计是对称加密为主，挂载时需要提供解密密钥（或者通过PAM自动加载），它的核心是让用户能在同一个设备上加密和解密文件，本质是“透明加密”——而你的需求是“单向写入，设备本身无法解密”，这和eCryptFS的设计目标完全不符，所以确实没法满足。

备注：内容来源于stack exchange，提问作者ecci