解释 admin 角色与 member 角色在数据库级 ACL 中的差异。
解读
在国内 CouchDB 面试中，这道题考察的是“能否把数据库级安全模型讲清楚”。很多候选人只背过“_users 库放账号、_security 放权限”，却说不清“为什么有 admin 还要有 member”。面试官想听的是：
- 这两个角色在数据库元数据层面到底控制了哪些操作；
- 它们与CouchDB 的 MVCC、设计文档、验证函数如何配合；
- 在多租户 SaaS、离线同步这类国内真实场景下，用错角色会导致什么线上事故。
答出“admin 能改库结构，member 只能读写普通文档”只是及格；能延伸到“_security 对象里 name 与 role 的继承关系、对 replicator 的影响、与 validate_doc_update 的交互”才能加分。
知识点
- 数据库级 ACL 的物理位置：每库的 _security 文档，结构固定为
{"admins":{"names":[],"roles":[]},"members":{"names":[],"roles":[]}}。 - admin 角色的权限：
- 更新 _security 本身；
- 写 设计文档（_design/*），即改视图、索引、validate 函数；
- 执行 压缩、视图清理、副本同步 等管理操作；
- 绕过 validate_doc_update 钩子，直接写库。
- member 角色的权限：
- 对普通文档（非 _design）执行 GET/PUT/DELETE；
- 受 validate_doc_update 约束，若验证函数抛 forbidden/unauthorized，则即使 member 也写不进去；
- 不能改动 _design、_security，也不能触发压缩、同步等管理 API。
- 继承顺序：如果用户同时出现在 admins.names 与 members.roles，admin 权限优先，不再走 member 校验。
- 国内常见误区：
- 把“_admin”这个服务器级超级用户与数据库级 admin 角色混为一谈；
- 在微服务架构中给应用账号配成 admin，导致设计文档被业务服务意外覆盖；
- 做离线同步时，只给移动端 member 权限，结果本地 _design 同步失败，引发“checkpoint 404”报错。
答案
在 CouchDB 的数据库级 ACL 中，admin 角色拥有“结构管理权”，而 member 角色仅拥有“数据读写权”。
具体差异如下：
- 能否修改 _security 文档：只有 admin 可以；member 即使拿到文档 ID 也返回 403。
- 能否写 _design/ 文档*：admin 可以，member 直接 403；这意味着视图、索引、validate 函数全部由 admin 管控。
- 是否受 validate_doc_update 限制：member 完全受验证函数约束；admin 可绕过，保证管理员能在数据违规场景下修复库。
- 能否调用 管理级 HTTP API（如 _compact、_view_cleanup、_replicate）：admin 可以；member 返回 403。
- 对普通 JSON 文档的 CURD：member 与 admin 都能操作，但 member 必须满足验证规则。
总结一句话：admin 管“库结构 + 权限 + 治理”，member 管“业务数据”；国内生产环境必须遵循“最小权限”原则，业务服务账号只给 member，运维脚本才用 admin。
拓展思考
- 如果公司在 Kubernetes 上跑 CouchDB 集群，给每个租户一个库，如何用 RBAC + _security 实现“租户只能改自己库的数据，不能改别人库的设计”？
答：在 helm values 里为每个租户注入独立的 Kubernetes ServiceAccount，通过 initContainer 调用 PUT /db/_security，把该 SA 的 OIDC role 写进 members.roles，把 SRE 组写进 admins.roles；这样租户 Pod 即使拿到 token 也只能读写数据，无法动视图，避免“一个租户上线坏视图导致全集群视图索引重建”的故障。 - 国内 移动 App 离线场景下，同步网关（PouchDB/Sync Gateway）常用 长轮询 _changes；若手机端账号只是 member，而本地数据库里带了 _design/sync-filter，会发生什么？
答：CouchDB 的 _replicator 在远端写 _design/sync-filter 时会因 403 被拒，导致 checkpoint 无法提交，同步陷入“无限重试”。正确做法是：把过滤视图提前由 admin 部署到云端库，移动端仅同步普通数据，既保证安全又避免死循环。 - 审计合规要求“谁改了视图必须可追踪”，如何利用 admin 与 member 的差异做技术落地？
答：在 validate_doc_update 里对 _design 文档强制要求 audit 字段（含工单号、审批人）；由于只有 admin 能写 _design，就能确保每条视图变更都带审计上下文；再配合 ELK 收集 /db/_design PUT 日志*，即可实现“结构变更可回溯”，满足国内金融、政企项目的等保要求。