不能靠禁止shell可执行权限限制MongoDB用户行为，因为权限由服务端RBAC控制，与本地工具执行权限无关；真正应启用security.authorization、在admin库创建用户并分配最小必要角色。
不能靠禁止 shell 可执行权限来限制 MongoDB 用户行为 —— 这是方向性错误。 MongoDB 的用户权限由服务端 RBAC（基于角色的访问控制）管理，和操作系统层面是否允许执行 mongosh 或 mongo 命令完全无关。禁止用户运行 shell 工具，既拦不住合法连接（比如应用代码、NoSQLBooster、Robo 3T），也拦不住恶意用户用其他方式连上数据库。
为什么禁用 mongosh 文件权限没用
常见误操作：给 /usr/bin/mongosh 加 chmod -x，或把文件 owner 改成 root 并移除 group/o 执行位。问题在于：
- 只要 MongoDB 实例开着、端口可访问，任何能发网络请求的程序都能连 —— 不依赖本地 shell
- 用户可能自己下载静态编译版
mongosh放到$HOME/bin，或用 Python +pymongo写个简易客户端 - 运维或开发机上通常有多个 shell 工具（
mongo、mongosh、mongostat、mongodump），逐个 chmod 不现实，还容易破坏自动化脚本
真正该锁住的是数据库服务端的认证与授权
所有权限控制必须落在 MongoDB 服务配置和用户角色上，核心动作只有三步：
- 确保
/etc/mongod.conf中启用了security.authorization: enabled - 只在
admin库创建用户，且绝不使用local库（db.createUser在local上直接报错Cannot create users in the local database） - 为每个业务用户分配最小必要角色，例如：
{ role: "readWrite", db: "app_logs" }，而不是root或userAdminAnyDatabase
验证是否生效：用新用户连接时，不加 --authenticationDatabase admin 参数会直接被拒绝；连上后执行 show dbs 只能看到被授权的库，对 config、local 等系统库不可见。
如果真要限制某台机器上的人“不能手敲命令”，得从访问路径入手
这不是数据库层的事，而是网络与系统策略问题。可行做法包括：
- 防火墙只放行应用服务器 IP 到 MongoDB 端口（如
27017），禁止开发/运维个人电脑直连 - 在跳板机或堡垒机上禁用交互式 shell（如用
rbash或scponly），或通过 SSH 强制命令（command="..."）限制只能跑备份脚本 - 用
mongosh的--eval模式配合 wrapper 脚本，只允许预设的几条只读命令（但绕过成本低，仅作辅助）
注意：mongosh --norc 或修改 .mongorc.js 是客户端体验优化，不影响权限逻辑；disablelogging: true 也只是关掉本地日志，不阻止命令执行。
最常被忽略的一点：即使用户无法执行 mongosh，只要他拿到连接字符串（含用户名密码）、且服务端没开 auth 或角色太宽，照样能用任意客户端删库。权限不在二进制文件里，而在 db.grantRolesToUser() 和 mongod.conf 里。
