acl不支持直接“只写不读”，但可通过分层设计实现：接入层禁用读接口、存储层代理写入并设私有acl、元数据层隔离不可见，辅以jwt签名、禁用propfind、写即焚等机制阻断侧信道。
ACL（访问控制列表）本身不直接支持“只写不读”这种反直觉的权限模型——因为标准ACL（如POSIX、Windows DACL或大多数文档系统底层ACL）的“写”操作通常隐含对元数据或内容的读取依赖（例如保存前需加载原文、校验版本、解析结构）。但通过分层设计+策略绕行，可在项目文档系统中近似实现“用户可提交/覆盖文档，但无法查看历史或当前内容”的效果。关键不在ACL单点配置，而在权限解耦与流程封装。
一、理解“只写不读”的真实约束
所谓“只写不读”，实际指：
- 用户能上传新文件、覆盖同名文档、提交表单或API写入内容；
- 但无法执行GET /docs/123、无法在Web界面打开预览、无法列出目录、无法查看修改记录或版本快照。
这要求将“写入口”与“读出口”彻底分离，并阻断所有隐式读路径（如HTTP HEAD、ETag校验、自动缩略图生成等）。
二、分层级ACL部署的三层结构
以典型项目文档系统（如Confluence插件、自研文档平台或基于MinIO+WebDAV的架构）为例：
- 接入层（API/Web端）：仅开放POST /api/v1/docs/{id}/submit 和 PUT /docs/{id}（带签名时效Token），禁用所有GET/HEAD/PROPFIND。前端不渲染文档内容区，只显示“提交成功”提示。
- 存储层（对象存储/数据库）：ACL按桶/集合隔离。用户写入时，服务端以系统账号（非用户身份）存入，对象ACL设为 private（如S3 ACL=private，MinIO policy=none），用户无任何直接GetObject权限；写操作由后端代理完成。
- 审计与元数据层：文档元数据（标题、作者、时间）存于独立DB表，该表对用户完全不可见；仅管理员可通过后台SQL查询。用户提交时，字段如“备注”“附件说明”可写入，但不回显、不索引、不关联可读视图。
三、关键技术实现要点
避免常见陷阱：
- 禁用WebDAV的PROPFIND和OPTIONS响应，否则暴露文件存在性与大小（变相泄露）；
- 所有写接口强制使用短期JWT（5分钟过期），Payload含一次性nonce，防重放；
- 若用Git作为文档后端（如docs-as-code），则用户仅推送至专用“ingest”分支（pre-receive hook校验格式），主分支受保护，且Git服务器关闭git-web、git-blame等读服务；
- 日志脱敏：Nginx/Apache access log 中屏蔽请求URL中的文档ID，仅记“/api/submit [200]”。
四、替代方案：用“写掩码”代替纯ACL
当底层存储不支持细粒度ACL（如老旧NAS或FTP），可采用间接方式：
- 用户上传至公共可写目录（如/sftp/inbox），文件名含UUID+时间戳；
- 后台定时任务（每2分钟）扫描该目录，校验格式后移入私有文档库，并立即删除源文件；
- 用户无权ls /sftp/inbox 历史文件（SFTP chroot + 无list权限），也无权读取已移走的文件——本质是“写即焚”模式。
不复杂但容易忽略：真正的“只写”必须切断所有侧信道。ACL只是工具，核心是让写动作不依赖读、不触发读、不留下可读痕迹。
