普通用户默认能读dmesg是因为内核参数kernel.dmesg_restrict=0，设为1后仅root可读，需配合加固/dev/kmsg权限至0600并验证生效。
普通用户默认能看 dmesg，要限制成仅 root 可读，核心是关掉内核的宽松访问开关。
为什么普通用户现在还能看到 dmesg 输出
Linux 内核有个运行时参数叫 kernel.dmesg_restrict，它控制非特权用户能否读取内核环形缓冲区。默认值是 0（允许），所以多数系统里普通用户敲 dmesg 就能直接看到日志。这不是权限位问题，也不是 /dev/kmsg 的文件权限导致的——是内核自己放行的。
设置 kernel.dmesg_restrict=1 立即生效
这条命令能立刻锁住非 root 访问：
sudo sysctl -w kernel.dmesg_restrict=1
执行后，普通用户再运行 dmesg 就会收到：
dmesg: read kernel buffer failed: Operation not permitted
注意：sysctl -w 是临时生效，重启就失效。如果要永久生效，得写进配置文件：
- 编辑
/etc/sysctl.conf，追加一行：kernel.dmesg_restrict = 1 - 或者新建
/etc/sysctl.d/99-dmesg-restrict.conf，内容只有一行：kernel.dmesg_restrict = 1 - 然后运行
sudo sysctl --system重载全部配置
别漏掉 /dev/kmsg 的权限配合
虽然 kernel.dmesg_restrict=1 已经拦住了 dmesg 命令，但有些程序会绕过它、直接读 /dev/kmsg。这个设备节点默认是 crw------- 1 root root，看起来安全，但某些发行版（如较新 Debian）可能改过 udev 规则，把它设成了可读。保险起见，检查并加固：
ls -l /dev/kmsg
如果输出里有 rw- 给 group 或 other（比如 crw-r-----），就说明非 root 用户可能通过其他方式读取。修复方法：
- 确认
/dev/kmsg权限是crw-------，如果不是，用sudo chmod 0600 /dev/kmsg - 更稳妥的做法是加一条 udev 规则：在
/etc/udev/rules.d/99-kmsg-perms.rules里写KERNEL=="kmsg", MODE="0600"，然后sudo udevadm control --reload-rules && sudo udevadm trigger
验证是否真生效了
切到普通用户（别用 sudo -u 模拟，要用真实非 root shell），执行：
dmesg | head -5
应该报错；再试：
cat /dev/kmsg | head -5
也应被拒绝（Permission denied）。只有 root 用户或加 sudo 才能成功。注意：journalctl -k 不受此限制影响，它走的是 systemd 日志管道，不是直接读 ring buffer —— 所以限制 dmesg 并不等于限制所有内核日志出口。
真正难搞的是那些依赖 dmesg 自动诊断的监控脚本，它们一旦跑在普通用户下，会突然失败。上线前务必在目标环境里用真实低权限账号跑一遍验证。
