必须将/etc/mongod.conf权限设为600，因其含security.keyfile、replsetname等敏感信息，644或755权限会使普通用户直接读取；设权前须确认运行用户、属主一致及目录有rx权限。
必须把 /etc/mongod.conf 权限设为 600，否则任何能登录系统的普通用户都能直接读取 security.keyFile、replSetName 甚至误写的日志路径——等于把数据库的钥匙挂在门把手上。
为什么 chmod 600 不是“加个权限”而是强制动作
MongoDB 配置文件不是普通文本，它常含以下敏感字段：
-
security.keyFile：副本集/分片集群认证用的密钥路径，文件内容本身即凭据 -
replication.replSetName：配合keyFile使用时，泄露该值可辅助攻击者构造握手请求 -
systemLog.path：可能暴露日志存放结构，结合其他漏洞可定位敏感文件 - 误写入的
setParameter或自定义脚本路径：可能带硬编码凭证或执行入口
一旦权限是 644 或 755，任意本地用户执行 cat /etc/mongod.conf 就能拿到全部信息。Git 提交、容器镜像打包、运维共享时极易扩散。
设成 600 之前必须确认三件事
盲目运行 chmod 600 /etc/mongod.conf 可能导致 mongod 启动失败——因为进程不以 root 运行，而以专用用户（如 mongod）身份启动。
- 查实际运行用户：
ps aux | grep mongod，看 USER 列（常见为mongod或mongodb） - 查当前属主：
ls -l /etc/mongod.conf，若 owner 不是上一步查到的用户，先执行sudo chown mongod:mongod /etc/mongod.conf - 查目录权限：
ls -ld /etc/，确保目录至少有rx（即755），否则进程连打开文件句柄都失败
chmod 600 后仍报 Permission denied？重点排查 SELinux 和 systemd
在 CentOS/RHEL 8+ 或启用 SELinux 的系统上，即使权限和属主都对，mongod 仍可能被拦截，日志只显示模糊的 Permission denied。
- 临时验证是否 SELinux 导致：运行
sudo setenforce 0，再sudo systemctl restart mongod；若成功，则问题确系 SELinux - 恢复并打标：
sudo semanage fcontext -a -t mongod_etc_t "/etc/mongod\.conf"，然后sudo restorecon -v /etc/mongod.conf - 若用 systemd 用户实例，检查
ProtectHome=true或RestrictPaths=是否意外屏蔽了/etc/下的读取：systemctl show mongod | grep Protect
自动化部署时避免“写完再改权”的时间窗口
Ansible 或 shell 脚本批量写配置时，不要用两步操作（先 echo ... > conf，再 chmod 600），中间存在毫秒级窗口，其他进程可能已读取明文。
- 推荐用
install -m 600 -o mongod -g mongod /dev/stdin /etc/mongod.conf，一次性完成写入、设权、设属主 - Ansible 中用
copy模块时，必须同时指定mode: '0600'、owner: mongod、group: mongod - 容器场景下，配置文件应挂载为只读卷，并在 entrypoint 中提前校验权限，而非靠 CMD 启动时依赖
最易被忽略的是：即使用了 keyFile，如果 mongod.conf 里还开着 bindIp: 0.0.0.0 或残留测试用户配置，权限再严也没用——配置文件本身就成了风险放大器。
