MongoDB自定义readWriteNoDelete角色仍可删除数据问题排查

你遇到的这个问题确实有点让人困惑——明明角色里没给delete权限，却还能执行删除操作。我来帮你梳理几个可能的原因和对应的解决步骤：

1. 会话权限未刷新 #

当你创建新角色并分配给用户后，当前的MongoDB会话可能还在使用旧的权限缓存。你需要重新认证用户，让新权限生效：

// 在admin数据库执行认证（因为你的用户是在admin库创建的）
use admin
db.auth("defaultuser", "你的密码")

之后切换回permitmanager库再尝试删除操作，看是否还能执行。

2. 用户拥有未被注意的额外角色 #

虽然connectionStatus显示了两个角色，但可能你的用户在admin数据库还拥有其他高权限角色（比如readWriteAnyDatabase、root等），这些角色会覆盖你自定义的权限限制。你可以通过以下命令查看用户的完整角色信息：

use admin
db.getUser("defaultuser")

检查返回结果中的roles数组，确认是否有其他超出预期的角色。如果有，需要移除这些多余的角色：

db.revokeRolesFromUser("defaultuser", [
  { role: "多余角色名", db: "admin" }
])

3. 角色定义未正确生效 #

你可以验证自定义角色readWriteNoDelete的实际权限是否符合预期：

use permitmanager
db.getRole("readWriteNoDelete", { showPrivileges: true })

查看返回的privileges部分，确认：

• 资源范围确实是permitmanager库的所有集合（resource: { db: "permitmanager", collection: "" }）
• 权限操作只有insert和update，没有delete或其他写权限

如果角色定义有误，你可以删除旧角色后重新创建：

use permitmanager
db.dropRole("readWriteNoDelete")
// 重新创建角色
db.createRole({ 
  role: "readWriteNoDelete", 
  privileges: [{ 
    resource: { db: "permitmanager", collection: "" }, 
    actions: ["insert", "update"] 
  }], 
  roles: [{ role: "read", db: "permitmanager" }] 
})
// 重新分配给用户（在admin库执行）
use admin
db.grantRolesToUser("defaultuser", [{ role: "readWriteNoDelete", db: "permitmanager" }])

4. 确认操作的数据库是否正确 #

有时候可能会不小心在错误的数据库执行操作，你可以先确认当前所在数据库：

db.getName()

确保返回的是permitmanager，再尝试删除操作。

额外提示 #

MongoDB中remove()、deleteOne()、deleteMany()这些删除操作都需要delete权限，只要你的角色中没有包含这个权限，用户就无法执行删除。如果以上步骤都排查过还是有问题，建议检查你的MongoDB版本（3.0及以上才支持细粒度角色权限），或者查看MongoDB的日志文件，看是否有相关权限验证的错误信息。

内容的提问来源于stack exchange，提问作者pasquers